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ABSTRACT 

A  new  notation  is  introduced  for  representing  real-time 
scheduling  at  the  task,  and  event  level.  These  schedules  are  called 
control  structures.  The  primary  constructs  Included  which  direct  the 
flow  of  control  are  sequencing,  iteration,  and  preemption.  Additional 
notation  allows  the  representation  of  interrupt  masking,  task 
termination  by  external  events,  task  restart  as  wall  as  resumption 
from  the  point  of  preemption  and  codestripping.  Algorithms  are  given 
for  finding  the  preemption  structure  of  a  given  control  structure  in 
the  notation. 

HM  typea  of  representable  control  structures  are  classified  by 
tfta  tapningy  of  their  Control  Flow  Graphs.  It  is  shown  that  although 
bMMhipg  ia  allowed  in  the  preemption  structure,  a  tree-shaped 
poaamfMao  alreetoae  cannot  be  represented.  Both  partial  and  total 

atdarinfs  of  iwha  and  tnterrnpt  yrtoritias  are  supported,  however. 

A  tannlnolnM'  ^  dwMibini  veal-tlaM  pn^erties  of  control 
structures  is  daveiofad,  and  M  ta  aean  tfwt  without  certain  assumptions 
about  task  execution  tteas  and  otmni  tnmnga.  eancinaions  cannot  be 
drawn  regarding  real-time  perfei manna  of  a  eaotsel  sweotnie.  A  series 
of  algorithms  Is  presented  which  make  use  ef  oammpMnna,  and 

find  values  for  task  execution  times  in  tho  ef  pseampttan. 

The  algorithms  can  analyse  control  structures  containing  u**  I’tactptf 
control  features;  suggestions  are  given  for  further  daeelaymMst  el 
algorithms  which  can  analyze  any  representable  control  structure. 
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It  Introduction 

In  an  article  entitled  “Toward  a  discipline  of  real-time  programming”  [Wirth 
77b],  Niklaus  Wirth  has  divided  programming  into  three  categories  based  on  the  In¬ 
creasing  complexity  of  validating  their  programs: 

1.  Sequential  programming 

2.  Multiprogramming 

3.  Real-time  programming 

In  a  real-time  system,  a  program  may  be  attempting  to  control  or  to  react  to 
certain  external  processes  which  cannot  be  forced  to  cooperate  with  programmed 
processes  through  use  of  a  synchronization  primitive  such  as  a  semaphore  [Dijkstra 
68]  or  a  monitor  [Hoare  74].  In  order  to  coordinate  Itself  with  these  external, 
non-programmable  processes,  the  reahtime  program  must  know  something  about  its 
own  execution  speed.  Thus  Its  correctness  will  be  dependent  on  the  speed  of  the 
processor  on  which  It  is  run;  but  this  Is  not  a  property  of  the  program  itself;  Wirth 
Identifies  this  as  the  essential  distinguishing  feature  of  real-time  programming. 

This  thesis  does  not  directly  address  the  issue  of  validating  real-time  programs. 
Instead,  It  deals  with  the  representation  of  schedules  for  real-time  programs  called 
control  struotur»s,  and  some  aspects  of  measuring  real-time  properties  of  the 
resulting  control  structures.  In  the  sense  that  knowledge  of  these  real-time  propei^ 
ties  may  be  a  prerequisite  for  validation  of  a  real-time  program,  the  work  presented 
here  does  represent  a  contribution  to  one  aspect  of  the  validation  problem. 
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1.1:  Related  Research 

Most  of  the  previous  studies  in  the  fleid  of  resl-tiine  programming  have  been 
centered  on  one  of  two  major  areas,  the  design  of  languages  for  real-time  program¬ 
ming,  and  scheduling  to  meet  real-time  deadlines. 

The  development  of  languages  for  real-time  programming  can  be  split  between 
two  approaches;  the  extension  of  existing  languages  [Benson  67;  Freiburghouse 
77;  Ormickl  77;  Phillips  76;  Wirth  77a],  and  the  creation  of  entirely  new  languages 
tailored  to  the  requiremehts  of  real-time  programs  [Hennessy  76;  Kieburtz  76; 
Schoefller  70].  The  essence  of  these  efforts  has  been  to  provide  some  interface 
between  the  real-time  program  and  the  scheduling  of  itself  and  other  programs,  ei¬ 
ther  through  access  to  the  processor's  interrupt  system,  clocks  and/or  timers,  or 
by  influencing  the  processor’s  scheduling  routines.  Such  features  provide  only  a 
low  level  capability  for  determining  a  process’  real-time  behavior;  in  some  cases  it 
may  be  possible  to  think  of  all  the  timing  interactions  that  could  impact  on  the 
correctness  of  a  real-time  system,  but  the  burden  of  doing  so  has  usually  fallen 
most  heavily  (and  often  totally)  on  the  programmer.  Decisions  as  basic  as  assign¬ 
ing  priorities  to  different  tasks  must  typically  be  made  by  manual  analysis,  in  the 
hope  that  nothing  has  been  overlooked.  As  the  size  of  the  system  increases,  the 
complexity  of  the  problem  grows  as  well,  until  manual  analysis  becomes  extremely 
tedious  and  error-prone,  if  not  Impossible. 

Ideally,  a  programmer  could  submit  his  real-time  response  requirements  along 
with  his  programs,  and  either  have  them  scheduled  appropriately,  or  be  tdd  that  his 
requirements  cannot  be  met  by  that  particular  system.  Some  systems  (such  as  the 
CONSORT  system  of  the  Domain  Specific  Systems  Research  group  at  MIT)  have 
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been  developed  which  can  do  this  for  a  limited  class  of  programs,  but  to  the 
author’s  knowledge  no  one  has  yet  created  a  system  to  do  this  in  general.  Howev¬ 
er,  considerable  research  has  been  done  on  scheduling  tasks  in  the  presence  of 
hard  real-time  deadlines. 

Most  of  the  significant  results  obtained  have  been  based  on  restricting  atten¬ 
tion  to  limited  classes  of  control  structure  types.  For  example,  in  a  multiprocessor 
environment  where  there  is  a  partial  ordering  of  tasks  but  no  iteration  outside  of 
tasks,  [Manacher  67]  gives  an  algorithm  which  will  construct  near-optimal  task  lists 
(execution  orderings)  for  almost  any  combination  of  task  run  times  and  deadlines. 
If  the  schedule  is  full  to  capacity  with  tasks  whose  completion  times  are 
guaranteed,  his  strategy  allows  the  system  to  take  on  additional  unguaranteed 
tasks  without  affecting  the  guaranteed  status  of  those  tasks  already  scheduled. 
His  scheme  does  not  consider  the  effects  of  preemption,  however.  Serlin  [Serlin 
72]  and  Liu  and  Layland  [Liu  73]  have  independently  studied  the  problem  of 
scheduling  tasks  which  are  iterated  but  have  no  relative  orderings.  Serlin  gives 
scheduling  algorithms  based  on  fixed  priorities,  time  slicing,  and  relative  urgency. 
The  last  is  a  dynamic  priority  scheme,  where  the  processor  re-evaluates  the  priori¬ 
ties  of  each  task  at  every  interrupt,  and  selects  for  execution  the  one  with  the 
earliest  deadline.  This  method  is  shown  to  produce  a  schedule  which  meets  real¬ 
time  deadlines  if  any  schedule  will,  but  Seriin’s  analysis  neglects  the  overhead  of 
context  switching. 

A  difrerent  approach  is  taken  by  [Hennessy  76;  Kieburtz  76]  in  their  micropro¬ 
cessor  language  TOMAL;  Instead  of  using  an  interrupt  system,  they  have  a  com¬ 
piler  insert  calls  to  a  task  control  monitor  (which  Is  created  along  with  the  complla- 
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tion  of  a  set  of  programs)  at  specific  points  In  the  compiled  code.  This  provides 
assurance  that  the  task  control  monitor  will  get  control  within  a  finite  and  bounded 
Interval,  after  each  codestrip,  as  the  code  between  monitor  calls  is  named.  This  Is 
similar  to  a  time  slicing  system  which  allocates  execution  time  in  fixed  amounts  to 
each  task,  but  the  time  slices  are  synchronized  with  program  execution.  The 
length  of  the  codestrip  is  determined  by  the  response  time  requirements  of  the 
task,  and  the  compiler  can  determine  whe^er  the  programmer  supplied  require¬ 
ments  are  in  conflict.  The  notation  given  In  this  thesis  has  the  capability  of 
representing  codestrips. 

A  work  which  is  related  to  the  present  one  and  in  fact  complementary  is  that 
of  Teixeira  [Teixeira  78].  Much  of  the  terminology  used  here  was  developed 
there,  particularly  that  of  Chapter  6,  where  algorithms  for  measuring  real-time  pro¬ 
perties  are  developed.  Teixeira  also  used  the  regular  expression  notation  of 
Chapter  2  to  denote  sequencing  and  iteration  of  tasks.  His  study  centers,  howev¬ 
er,  on  finding  schedules  to  meet  real-time  constraints;  the  orientation  of  the 
present  work  is  described  in  the  following  section. 


1.2t  Objectives 

The  principal  goal  of  this  research  Is  twofold;  to  develop  a  convenient 
representation  for  real-time  control  structures,  and  to  demonstrate  how  such  a 
representation  is  useful  as  a  basis  for  analyzing  real-time  properties  for  specific 
control  structures. 

The  reprcMentation  as  developed  models  control  structures  at  the  task  and  in- 
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terrupt  level;  the  tasks  are  assumed  to  be  self-contained  program  units  whose  ex¬ 
ecution  time  is  bounded,  and  interrupts  are  represented  as  occurrences  of  event 
variables.  The  event  variables  could  be  used  to  represent  any  event  however, 
which  might  be  synchronous  or  asynchronous  with  respect  to  the  executing  task. 
The  notation  can  represent  total  and  partial  orderings  among  its  tasks,  and  iteration 
of  tasks  at  a  single  priority  level  or  across  several  priority  levels.  As  well  as 
representing  conventional  single  and  multi-level  Interrupt  structures,  the  control 
structures  given  here  can  represent  several  unconventional  preemption  structures. 
Including  branched  structures  where  each  branch  has  an  Individual  preemption 
structure  which  may  itself  be  branched. 

As  well  as  representing  this  basic  framework,  the  capability  is  provided  to 
represent: 

1.  Codestripping  as  previously  described. 

2.  External  termination  of  a  task  or  group  of  tasks  by  an  event 
occurrence  (as  opposed  to  temporarily  preempting  them). 

3.  Indication  that  a  task  or  group  of  tasks  Is  not  preemptible  by 
a  set  of  events. 

4.  The  choice  between  restarting  a  preempted  task  or  group  of 
tasks  from  the  beginning  vs.  resuming  execution  from  the  point  of 
interruption. 

Thus  a  rather  general  notation  Is  given,  which  in  addition  represents  all  of  this  in¬ 
formation  rather  compactly.  The  notation  may  be  used  In  any  application  where  it 
is  necessary  to  communicate  something  about  a  control  structure  of  this  sort,  be  it 
human  to  human,  human  to  machine,  or  machine  to  machine.  In  the  second  case, 
the  apeciflc  applications  in  mind  are  representation  of  a  contrtX  structure  for 
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anslysis,  and  for  describing  to  a  reat-time  system  what  sort  of  control  structure  It 
should  establish  for  a  set  of  tasks  with  real-time  constraints.  In  this  vein,  the  no¬ 
tation  is  quite  Independent  of  machine  architecture,  and  thus  a  subset  of  the 
language  can  be  chosen  for  a  target  machine  which  supports  the  control  features 
included  therein. 

This  leads  into  the  second  goal  of  the  investigation,  which  is  to  demonstrate 
how  algorithms  can  be  developed  which  ascertain  real-time  properties  for  control 
structures  of  the  language.  There  are  several  time  Intervals  which  are  probably  of 
common  Interest  to  a  large  segment  of  users  of  real-time  programs,  such  as: 

1.  The  maximum  delay  between  the  occurrence  of  an  event  and 
the  Initiation  of  its  program. 

2.  The  maximum  time  required  to  execute  a  set  of  tasks  at  a 
given  priority,  with  preemption. 

3.  The  maximum  time  that  may  elapse  without  there  being  an  ex¬ 
ecution  of  a  given  set  of  tasks. 

This  Is  not  intended  to  be  an  exhaustive  survey  of  real-time  properties,  but  rather 
an  introduction  to  the  usage  of  the  notation  as  the  foundation  for  such  analysis. 
Indeed,  It  Is  likely  that  each  real-time  system  has  its  own  special  requirements  and 
characteristics;  it  is  hoped  that  an  appropriate  subset  of  the  language  can  be 
chosen  to  model  those  characteristics,  and  algorithms  developed  which  are  suited 
to  an  application's  special  needs.  In  addition,  many  applications  will  have  natural 
restrictions  which  lead  to  simpler  algorithms;  it  is  with  Intent  of  illustrating  this 
point  that  several  special  case  algorithms  are  developed. 
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1.3:  Outline  of  the  Thesis 

The  next  chapter  presents  a  context  free  grammar  for  the  controi  structure 
language,  as  well  as  giving  the  semantics  for  each  construct.  Sequencing,  iteration 
and  preemption  are  the  principal  features,  with  extensions  added  as  described  In 
Section  1.2.  Methods  of  determining  the  overall  preemption  structure  of  a  control 
structure  are  also  presented. 

Having  introduced  the  notation.  Chapter  3  presents  the  concept  of  a  Control 
Flow  Graph  (CFG)  [Allen  76;  Fosdick  76],  which  gives  a  graphic  representation  for 
the  paths  of  control  flow  dictated  by  a  given  control  structure.  A  definition  of  ab* 
solute  priority  levels  Is  derived  from  a  contrc^  structure's  CFG  representation.  Then 
a  classification  of  control  structure  types  representable  by  the  notation  is  given, 
based  on  the  topology  of  their  CFG's.  In  addition,  some  types  of  control  structures 
which  are  not  representable  are  described. 

A  terminology  for  real-time  properties  of  control  structures  is  developed  in 
Chapter  4;  the  requirements  for  knowing  certain  things  about  event  timings  In  ad¬ 
vance  Is  also  discussed  here. 

This  leads  into  Chapter  6,  where  a  hierarchical  series  of  algorithms  Is  present¬ 
ed  which  are  designed  to  And  the  worst  cases  for  some  of  the  reaFtime  properties 
of  Increasingly  complicated  classes  of  control  structures.  The  most  general  algo¬ 
rithm  given  Is  applicable  to  the  set  of  controi  structures  which  includes  the  basic 
framework  of  sequencing.  Iteration  and  preemption.  The  types  of  modifications 
which  would  be  required  to  analyze  any  representable  control  structure  are  dis¬ 
cussed,  although  detailed  algorithms  are  not  given. 


2:  A  Notation  for  Raal-tlffla  Control  Structuras 


2.1:  Introduction 

In  this  chapter  a  notation  for  representing  real-time  control  structures  will  be 
developed.  The  intention  is  to  provide  a  general  analytical  tool  which  will  be  suit¬ 
able  for  representing  most  of  the  possible  ways  to  share  a  processor  among  the 
members  of  a  set  of  tasks.  This  will  include: 

1.  Sequencing:  a  total  ordering  of  tasks  to  be  executed. 

2.  Iteration:  cyclic  execution  of  some  ordered  set  of  tasks. 

3.  Preemption:  a  partial  ordering  of  tasks  where  the  occurrence 
of  an  event  forces  termination  of  execution  of  the  currently  run¬ 
ning  task  and  starts  execution  of  a  new  task. 

A  contex^free  grammar  will  be  developed  to  define  the  syntax  of  the  representa¬ 
tion.  It  Is  summarized  in  Appendix  A. 


2.2:  The  Basic  Control  Structure 

The  resKime  system  to  be  represented  is  modelled  as  a  set  of  procedures  to 
be  run,  called  tasks,  a  control  structure  which  specifies  the  order  (or  possible  ord¬ 
ers)  In  which  the  tasks  may  be  run,  and  a  processor  which  executes  the  tasks  ac¬ 
cording  to  the  scheduling  constraints  specified  by  the  control  structure. 

Thus  the  flow  of  data  between  tasks,  if  there  Is  any,  need  not  be  a  ooncem; 
It  Is  assumed  that  any  execution  ordering  needed  to  preserve  the  intended  seman- 
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tics  of  the  computation  (data  flow)  wilt  be  embodied  in  the  controt  structure.  For 
example,  If  an  output  of  task  A  is  an  input  of  task  B,  then  the  control  structure  as¬ 
sociated  with  their  execution  should  ensure  that  task  A  completes  execution  be¬ 
fore  task  B  begins. 

Further,  the  detailed  flow  of  Information  and  control  within  a  task,  i.e.  among 
Its  internal  variables  and  instructions  respectively,  need  not  be  of  concern  either. 
It  is  only  necessary  that  an  upper  bound  on  the  execution  time  of  a  task  be  esta¬ 
blished:  this  is  discussed  further  In  Section  4.2. 

A  task  will  be  represented  by  a  task  Identifier  (''<task  id>”),  which  in  most  of 
the  examples  will  be  a  single  capital  letter  (though  it  need  not  be).  Figure  2.1 
shows  the  grammar  which  defines  task  Identifiers. 

<task  ld>  ::s  <ietter>'|  <task  id>  <alphanumeric> 

<lotter>  A  I  B  I  C  I  ...  I  Z 
<alphanumerlc>  <letter>  |  <diglt> 

<cHgit>  0  I  1  I  2  I  ...  I  g 

Pig.  2.1.  Syntax  for  task  identifiers. 

Next  to  a  single  task,  the  simplest  thing  to  represent  is  the  sequencing  of  two 
or  more  tasks  which  are  totally  ordered.  This  is  done  in  the  natural  way,  by  listing 
the  task  Identifiers  In  the  order  of  execution  of  their  corresponding  tasks,  separa^ 
ed  by  blank  spaces  for  parsing.  A  string  of  one  or  more  tasks  will  be  called  a 
bas/c  control  structure,  or  <baslc  cs>.  Note  that  it  Is  permissible  to  list  a  task  Id 
more  than  once  In  a  <baslc  cs>,  to  represent  the  situation  where  the  corresponding 
task  is  executed  more  than  once  with  zero  or  more  other  task  executions 
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sandwiched  In  between.^  The  syntax  is; 

<bssic  cs>  <task  id>  |  <baslc  cs>  if  <ta8lc  id> 

where  "If  represents  the  blank  space  terminal  symbol. 

The  simplest  control  structure  is  Just  a  basic  control  structure: 

<control  8tructure>  ::s  <basic  cs> 

Thus  the  grammar  given  so  far  Is  sufficient  to  represent  single  task  execution  and 
sequenced  task  execution  control  structures. 


2.3;  Flow  of  Control 

It  is  useful  to  formalize  the  notion  of  control  flow  with  respect  to  control  struc¬ 
ture  execution.  The  processor  follows  the  "instructions"  supplied  by  a  control 
structure,  doing  both  "applicatlons-oriented”  work  (when  it  is  actually  executing  the 
statements  of  a  task),  and  "systems-orlented"  work  (when  it  is  determining  which 
task  to  execute  next  according  to  the  constraints  embedded  in  the  control  struc¬ 
ture).  in  either  case,  the  actual  machine  instructions  being  executed  at  any  time 
will  be  associated  with  a  particular  symbol  in  the  control  structure  representation; 
It  will  be  said  that  at  that  time  the  focus  of  control  (abbreviated  LC)  is  at  that 
symbol.  For  example,  in  the  following  control  structure: 


1.  Every  occurrence  of  a  task  id  in  a  control  structure  represents  a  separate  in¬ 
stantiation  of  that  task,  with  Its  own  privste  state.  This  is  used  to  model  reen- 
trantly  coded  routines. 
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AB 

whon  Instructions  of  tssk  A  srs  sxscuting,  LC  Is  at  A;  when  instructions  of  task  B 
aro  sxscutina.  LC  la  at  B. 


2.4:  Closad  Control  Structures 

It  is  desirable  to  Introduce  parenthesizatlon  for  the  grouping  of  task  id’s  in  the 
natural  way.  In  particular,  this  will  be  needed  to  Indicate  the  scope  of  the  various 
special  symbols  which  will  be  used  for  Iteration,  preemption,  etc.  It  will  also  be 
helpful  in  constraining  the  class  of  legal  control  structures  to  exclude  nonserwical 
ones,  such  as  those  In  which  some  tasks  can  never  execute,  regardless  of  preemp* 
tion  timing  considerations.  Parenthesized  (sub-)control  structures  will  be  called 
dosed  control  structures,  and  the  class  will  be  added  to  as  necessary  for  addition* 
al  representationai  power.  At  the  top  level,  closed  control  structures  will  be  includ* 
ed  in  the  set  of  legal  control  structures.  Figure  2.2  gives  the  syntax  for  closed 
control  structures;  a  syntax  Is  also  given  for  closed  control  structure  lists,  which 
will  be  needed  later  to  represent  more  complex  control  structures. 

<control  structure>  <baslc  C8>  |  <closed  C8> 

<closed  cs>  «ba8ic  cs»  |  (<closed  C8>  <basic  cs»  |  (<clo8ed  cs  Ii8t» 
<closed  cs  nst>  <closed  C8>  |  <cio8ed  cs  Hst>  <clo8ed  C8> 

Fig.  2.2.  Syntax  for  closed  control  structures. 
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lA  WfHoii 

Mss*  rea^tlM  process  control  applicstions  require  the  periodic  repetition  of  a 
opftets  leek  er  aeqpoiiee  of  tasks.  Borrowina  from  the  notation  of  regular  expres¬ 
sions,  the  aatsftss  m  wmmd  ta  Mtasts  a  ondless  repetition  of  a  control  structure. 
Its  BNF: 

<lterative  cs>  <bsslc  es>*  |  <olsses  «a»*  |  <oealc  es>  <ltorstlwe  cs> 

The  use  of  Is  most  easily  explained  by  axssplos: 

A  B*  =  A(B)*  £  A  B  B  B  B  B  ... 

(A  B)*  £  A  B  A  B  A  B  ... 

From  a  flow  of  control  viewpoint,  when  tC  reaches  an  asterisk  following  a  right 
parenthesis,  It  returns  to  the  matching  left  parenthesis.  If  it  reaches  an  asterisk 
following  a  task  id,  It  repeats  that  task. 

The  final  expansion  of  the  top-level  defhrltion  of  control  structure  is: 

<eontrol  structure>  <basic  cs>  |  <ciosed  cs>  |  <iteratlve  cs> 

2.6:  Preemption 

2.6.1:  Preemptible  Control  Structures 

With  the  class  of  control  structures  defined  so  far,  the  only  execution  se¬ 
quences  possible  are  those  In  which  the  order  of  task  execution  Is  entirely 
predetermined  (static).  In  many  situations,  a  processor  urill  need  to  respond  to 
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asynchronous  events  such  as  interrupts^  which  may  not  occur  at  predictable  times. 
It  may  be  desirable  to  have  such  events  trigger  the  execution  of  a  different  part 
of  the  control  structure  than  was  previously  in  control.  Informally,  this  will  be 
modelled  by  placing  sub-control  structures  into  the  overall  control  structure  in  order 
of  non-decreasing  priority.  Demarcation  of  the  priority  levels  is  achieved  by  Indi¬ 
cating  that  a  control  structure  Is  preempt/b/e.  Figure  2.3  gives  the  syntax  for 
preemptible  control  structures.  Preemption  is  initiated  by  occurrence  of  a  particu¬ 
lar  event  (which  may  be  complex),^  so  an  event  variable  is  Included  which  stands 
for  the  event. 

<preemptlble  cs>  <control  8tructure>  /  <event  var> 

<event  var>  e<integer> 

<inteoer>  <digit>  |  <integer>  <dlgit> 

<oloaed  es>  (<baslc  cs»  |  (<clo8ed  C8>  <basic  cs>)  |  (<closed  cs  Ii8t»  | 
(<preemptible  cs»  |  (<closed  cs>  <preemptible  cs» 

1^.  SyiilaK  for  preeaiptible  control  structures. 

Consider  the  foWowfm  ahaple  mmmmiam.  wWch  medeta  a  control  structure  with  a 
single  level  of  Interruption: 

((AVo1)B)* 

The  interpretation  of  this  control  structure  is  that  A  runs  rapastedhf  ■PM  meema  e* 


1 .  Tha  event  variable  Itself  Is  not  complex,  but  It  may  represent  a  complex  event. 
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happens;  this  Initiates  B,  which  executes  once;  then  LC  returns  to  A”. 

The  next  section  will  describe  how  more  complex  control  structures  are 
represented  (using  the  above  syntax),  such  as  those  having  multiple  levels  of 
Interruption. 


2.6.2:  Multiple  Priority  Level  Control  Structures 

Informally,  event  variables  lie  at  the  Interface  between  control  structures  of 
different  priority,  the  control  structure  to  the  left  of  the  '7<event  var>''  construc¬ 
tion  having  the  lower  priority.  If  LC  is  in  the  lower  priority  control  structure  when 
the  event  happens,  it  will  move  to  the  control  structure  immediately  to  the  right  of 
the  event  variable. 

Thus  a  control  structure  with  three  priority  levels  might  appear  as*. 

(((((A  B)*/e1)C  0)/e2)E)« 

The  preemption  structure  (for  each  event,  the  tasks  which  it  may  preempt)  is  fairly 
straightforward  here;  el  preempts  A  or  B,  e2  preempts  A,  B,  C  or  D.  But  the  nota¬ 
tion  is  capable  of  representing  more  complex  control  structures,  and  a  method  of 
precisely  determining  the  preemption  structure  Is  needed. 

The  "Interrupts"  or  "preempts"  relation  is  transitive;  if  el  interrupts  A,  Initiat¬ 
ing  C,  and  C  is  interruptible  by  e2,  then  A  is  interruptible  by  e2.  Moreover,  all 
tasks  of  a  single  basic  control  structure  will  nm  at  the  same  priority  level,  so  basic 
control  structures  can  be  considered  as  units,  rathar  than  examining  the  preemp- 


1.  Although  a  later  section  will  Introduce  the  capability  of  masking  specific  Inter- 
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tion  of  individual  tasks.^ 

The  "interrupts"  relation  will  now  be  formalized,  i.e.  it  will  be  established  clears 
ly  for  each  event  in  a  control  structure  which  basic  control  structures  it  may 
preempt.  The  set  of  tasks  which  are  interruptible  by  a  certain  event  will  be  re¬ 
ferred  to  as  the  scope  of  that  event.  The  "interrupts"  relation  for  a  control  struc¬ 
ture  will  be  represented  by  a  Boolean  matrix  I  with  n  rows  and  columns,  where  n  is 
the  number  of  basic  control  structures  in  the  control  structure  being  analyzed.  A 
single  basic  cs  Is  associated  with  each  row  /  and  column  /,  for  1  ^  ^  n.  The 

basic  cs  associated  with  row  (and  column)  /  will  be  referred  to  as  "basic  cs  /." 

The  first  event  to  the  left  of  each  basic  cs  will  be  called  that  basic  cs’s  Ini¬ 
tiating  event.  If  ![/,/]  =  1,  it  means  that  basic  cs  /  runs  at  a  higher  priority  than 
basic  cs  ji  in  particular,  it  means  that  basic  cs  Ps  Initiating  event  can  preempt 
basic  cs  J.  The  matrix  I  Is  computed  according  to  the  algorithm  given  in  Figure  2.4. 

This  matrix  specifies  which  events  cause  preemptions  across  the  border 
between  adjacent  priority  levels.  Since  the  "interrupts"  relation  is  transitive,  the 
transitive  closure  of  this  initial  relation  is  the  complete  preemption  structure;  this 
specifies,  for  each  event  in  the  control  structure,  exactly  which  basic  cs’s  it  can 
preempt.  Computing  the  transitive  closure  of  the  relation  represented  by  I  is 
straightforward.  Lot  1+  be  the  transitive  closure  of  I.  Then  1+  *  I  ♦  ♦  l”, 

whore  *  Is  normal  matrix  addition.  Boolean  matrix  multiplication  is  performed  like 
regular  matrix  multiplication  except  'AND’  is  substituted  for  'TIMES’  and  'OR’  for 


rupts  while  a  particular  task  Is  executing. 
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Algorithm  2.1 1 

1 .  Let  n  be  the  number  of  basic  cs’s  in  the  control  structure.  As* 
soclate  a  unique  integer  from  1  to  n  with  each  basic  cs. 

2.  Initialize  I  to  be  an  nun  matrix  of  zeroes. 

3.  For  each  basic  cs  1,  do  steps  4  and  6. 

4.  If  basic  cs  /  has  no  Initiating  event,  leave  row  /  of  I  equal  to 
all  zeroes. 

6.  If  basic  cs  /  has  an  initiating  event  e,  find  the  control  struc* 
ture  Immediately  preceding  the  construction  “/e."  Call  this  "con¬ 
trol  structure  A."  By  the  syntax  of  preemptible  control  structures, 
control  structure  k  will  be  either  a  basic,  closed  or  iterative  cs. 
For  each  basic  cs  J  in  control  structure  k,  set  l[/,y]  equal  to  1 . 

Fig.  2.4.  Computing  the  matrix  I. 


•PLUS*. 

Consider  an  example  of  a  control  structure  which  contains  preemptible  control 
structures,  and  which  can  be  used  to  illustrate  the  construction  of  the  "interrupts" 
relation: 


Example  2.1.  (((((A  B)Ve1)C)Ve2)((D/o3)E))" 


Notice  that  this  control  structure  contains  four  basic  control  structures,  A  B,  C,  D 
and  E.  The  Initiating  events  for  these  basic  cs’s  are  as  specified  in  Figure  2.6. 


Basic  CS 

Initiating  Event 

Row/Column  of  I 

H9i 

none 

1 

el 

2 

e2 

3 

_ E _ 

ea 

4 

Fig.  2.6.  Initiating  events  for  Example  2.1. 


The  matrix  I  Is  formed  following  Algorithm  2.1 ,  and  it  appears  In  Figure  2.6. 
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1 .  A  B  has  no  Initiating  event,  so  row  1  s  [0  0  0  0] 

2.  C’s  initiating  event  is  el.  The  control  structure  preceding  e1 
is  (A  B)*,  which  contains  the  basic  cs  A  B.  Thus  i[2, 1  ]  :s  1 . 

3.  D’s  initiating  event  is  e2.  The  control  structure  preceding  e2 
Is  ((A  B)*/e1)C)*  which  contains  the  basic  cs’s  A  B  and  C.  Thus 
I[3,1]  ;*  1  and  l[3,2]  :=  1. 

4.  E*s  initiating  event  is  e3.  The  control  structure  preceding  e3 

is  D.  Thus  l[4,3]  1. 


I 

ABC  D  E 

A  B 
C 

D 

E 

0  0  0  0 
10  0  0 
110  0 

0  0  10 

Fig.  2.6.  The  I  matrix  for  Example  2.1. 

Now,  to  get  the  overall  preemption  structure,  compute  l-t-,  the  transitive  closure 
of  I,  as  shown  in  Figure  2.7. 


1+ 

ABC  D  E 

A  B 

C 

0 

E 

0  0  0  0 
10  0  0 
110  0 
1110 

Fig.  2.7.  K  for  Example  2.1. 


The  preemption  relations  of  the  control  structure  are  summarized  in  Figure  2.8. 
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LC  at 

Preemptible  by 

Initiates 

A  or  B 

el 

C 

A  or  B 

e2 

D 

A  or  B 

ea 

E 

C 

e2 

D 

C 

03 

E 

D 

e3 

E 

E 

none 

none 

Fig.  2.8.  Preemption  structure  for  Example  2.1. 


2.6.3:  Occurrence  of  Events 

The  notion  of  an  event  "happening"  Is  purposefully  left  vague;  each  applica¬ 
tion  of  the  notation  can  attach  Its  own  meaning.  For  the  purpose  at  hand  it  is 
sufficient  to  assume  that  an  event  variable  is  like  a  flag^  which  gets  set  when  Its 
associated  event  occurs.  The  processor  checks  all  the  event  variables  before  be¬ 
ginning  execution  of  every  instruction.  The  following  informally  describes  what  hap¬ 
pens  if  any  flag  is  found  to  be  set: 

1.  In  the  case  where  LC  is  to  the  right  of  the  event  variable 
which  has  been  set,  no  Immediate  effect  on  execution  of  the 
currently  running  task  results.  The  currently  running  task  is  of  a 
higher  priority  than  that  which  Is  requesting  the  interrupt. 

2.  The  event  variable  remains  set  until  such  time  as  LC  is  to  the 
left  of  it  and  in  a  basic  cs  which  Is  preemptible  by  it,  at  which 
time  It  will  cause  a  preemption. 

3.  If  more  than  one  event  corresponding  to  event  variables  to 
the  right  of  LC  has  happened,  then  the  rightmost  one  represents 
the  highest  priority  interrupt  (request),  and  LC  moves  to  the  right 


1.  Generally,  a  queue  of  requests  Is  associated  with  a  given  event  variable,  so 
that  additional  occurrences  of  the  event  will  be  remembered  if  they  occur  before 
the  Initial  occurrence  Is  noted  by  the  processor.  By  specifying  a  length  for  this 
queue,  a  system  which  remembers  an  arbitrary  number  of  event  occurrences  can 
be  modelled. 
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of  it  (assuming,  of  course,  that  LC  was  within  a  basic  cs  preempti¬ 
ble  by  the  event). 

4.  Completion  of  the  control  structure  at  a  given  priority  "resets" 
the  event  variable  which  triggered  Its  execution;  note  that  this 
must  be  done  at  completion  rather  than  at  initiation  so  that  if  the 
control  structure  Is  preempted  before  it  completes,  then  LC  will 
return  to  it  when  it  is  once  again  the  highest  priority  control 
structure  requesting  processor  service. 


2.6.4:  Substructure  at  a  Single  Priority  Level 

A  useful  extension  to  the  scheme  is  to  provide  for  arbitrarily  many  control 
structures^  to  reside  at  the  same  priority  level,  but  to  be  initiated  by  different 
events.  During  execution  of  one  of  these  control  structures,  occurrence  of  events 
In  the  other(s)  at  the  same  priority  level  will  have  no  (preemptive)  effect.  The 
principle  syntactic  change  is  to  allow  replacement  of  an  event  variably  by  an  event 
coup/ed  list,  as  shown  in  Figure  2.0. 

<preemptlble  cs>  <control  structure>  /  <event  llst> 

<event  list>  <event  var>  |  «event  coupled  list>)  | 

(<event  coupled  llst»* 

<event  coupled  llst>  <event  var>:  <control  structure>  ) 

<event  coupled  list>  'f  <event  var>:  <control  8tructure> 
where  '|’  means  the  terminal  symbol  |. 

Pig.  2.9.  Syntax  for  event  coupled  preemptible  control  structures. 


1.  Of  arbitrary  complexity,  e.g.  there  may  be  additional  local  priority  structure. 
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Consider  an  example: 

(A*/(e1:  B  I  e2:  C))“ 

Preemption  rights  are  as  follows: 


LC  at 

Preemptible  by 

Initiates 

A 

el 

B 

A 

e2 

C 

B  or  C 

rxjne 

none 

Execution  of  B  or  C  continues  uninterrupted  to  termination.  Termination  of  B  or  C 
returns  LC  to  A  (unless  el  or  e2  has  happened  again). 

A  slight  modification  in  the  position  of  the  terminal  leaves  the  interrupt  struc¬ 
ture  the  same  but  results  in  different  behavior  on  termination  of  B  or  C; 

(AV(e1:  B  |e2:  C)*) 

The  idea  here  is  that  once  either  B  or  C  has  been  initiated  (through  occurrence  of 
e1  or  e2,  respectively),  control  is  never  again  returned  to  A.  instead,  B  and  C  will 
be  executed  every  time  el  or  e2  occurs. 


2.6.5:  Determining  the  Interrupt  Structure 

Since  arbitrary  control  structures  may  reside  in  an  event  coupled  list,  it  follows 
that  such  structures  may  contain  additional  events  (or  event  coupled  lists)  which 
trigger  even  more  deeply  nested  control  structures. 


This  ability  to  nest  control  structures  raises  a  new  semantic  issue;  what 
should  be  the  scope  of  events  which  are  not  at  the  top  level  In  the  event  coupled 
list?  The  choice  made  here  is  to  let  any  event  In  an  event  coupled  list  have  the 
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same  scope  external  to  the  event  coupled  list  that  an  event  variable  would  have  if 
it  were  substituted  for  the  event  coupled  list.  Consider  the  following: 

Example  2<2.  (A/(e1  :((B/e2)C)|e3:((D/e4)E)))* 

The  scope  of  e1.  e2,  ed  and  e4  external  to  the  event  coupled  list 
(e1  :((B/e2)C)|e3:((0/e4)E))  is  the  same  as  that  of  e5  in: 

(A/e6) 

namely,  the  control  structure  to  the  left  of  the  slash  in  the  construction  ''/(<event 
coupled  list>)". 

The  initiating  events,  as  shown  in  Figure  2.10,  are  determined  as  before:  the 
first  event  variable  to  the  left  of  each  basic  cs.  The  internal  scope  of  the  event 
variables  Is  somewhat  different,  though.  Events  In  event  coupled  lists  may  not 
preempt  any  task  in  the  list  which  is  separated  from  the  event  by  a  "I".  Thus  in 
the  above  example,  e3  and  e4  may  not  preempt  B  or  C.  Therefore  Algorithm  2.1 
must  be  modified  to  reflect  this.  Figure  2.1 1  shows  the  resulting  algorithm. 


Basic  cs 

Initiating  event 

A 

none 

B 

el 

C 

e2 

D 

e3 

E 

e4 

Fig.  2.10.  Initiating  events  for  Example  2.2. 
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Algorithm  2.2: 

1.  Let  n  be  the  number  of  basic  cs’s  In  the  control  structure 
under  examination.  Associate  a  unique  integer  from  t  to  n  with 
each  basic  cs. 

2.  Initlaiize  I  to  be  an  nxn  matrix  of  zeroes. 

3.  For  each  basic  cs  i,  do  steps  4  and  5. 

4.  if  basic  cs  /  has  no  initiating  event,  leave  row  I  of  I  equal  to 
all  zeroes. 

6.  If  basic  cs  /  has  an  initiating  event  e.  then  this  event  appears 
in  either  a  "/e"  construction  or  a  "le*  construction. 


a.  If  e  appears  In  a  "/e”  construction,  call  the 
control  structure  Immediately  preceding  "/e" 
“control  structure  k."  For  each  basic  cs  j  in  con¬ 
trol  structure  A.  set  l[/J]  equal  to  1. 

b.  If  e  appears  In  a  "|e“  construction,  then  e 
cannot  preempt  any  other  basic  cs’s  in  the 
event  coupled  list  of  which  it  is  a  member.  Its 
scope  starts  at  the  control  structure  to  the  left 
of  the  In  the  construction  “/«event  coupled 
Ust>)".  This  will  be  the  control  structure 
preceding  the  first  unmatched  left  parenthesis 
to  the  left  of  e.  Call  this  “control  structure  A." 

For  each  basic  cs  j  In  control  structure  A,  set 
([U]  equal  to  1 . 

Fig.  2.11.  Computing  I  for  cs’s  containing  event  coupled  lists. 


The  control  structure  of  Example  2.2  has  the  following  preemption  relation¬ 
ships: 


LC  at 

Preemptible  by 

A 

el,  e2,  e3,  e4 

B 

e2 

C 

ftone 

D 

e4 

E 

none 

.20. 
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Since  two  or  more  tasks  may  reside  at  the  same  priority  level,  such  as  B  and  C 
above,  a  natural  question  arises;  what  happens  if  both  e1  and  e3  occur  "simultane¬ 
ously,"  at  least  within  the  resolution  of  the  interrupt  system.^  Most  systems  adopt 
some  arbitrary  metric  to  resolve  such  situations.  A  typical  one  is  the  distance  of 
the  Interrupting  device  from  the  CPU.  A  similar  approach  is  taken  here,  if  more 
than  one  event  is  found  to  have  occurred  at  the  same  priority  level,  then  control  is 
arbitrarily  given  to  the  Srst  (leftmost)  one  in  the  event  coupled  list. 

However,  with  the  addition  of  event  coupled  lists,  "forks"  are  introduced  into 
the  preemption  structure,  as  shown  In  Figure  2.12.  A  diagram  such  as  this  is  called 
a  Control  Flow  Graph,  and  will  be  defined  formally  and  used  extensively  in  the  next 
chapter.  For  now  it  is  sufficient  to  note  that  this  diagram  "unravels"  the  preemp¬ 
tion  structure  so  that  the  relative  priority  levels  of  each  task  are  displayed.  If  two 
or  more  events  happen  together,  priority  is  given  to  the  event  which  Initiates  the 
task  having  higher  priority,  as  was  done  before.  In  the  above  example,  if  el  and 
e4  happen  simultaneously  control  is  given  first  to  E  (which  e4  initiates). 


el/  I  \e3 

/  I  \ 

B  i  D 

I  /  \  I 

e2j  e2  e4  je4 

1/  \l 

C  E 

Fig.  2.12.  Preemption  structure  for  Example  2.2. 

1.  Typically  the  presence  of  interrupt  requests  will  be  checked  for  once  per  in¬ 
struction  cycle,  so  any  interrupts  happening  between  two  such  checks  will  be  indis¬ 
tinguishable  as  to  their  ordering  in  time. 
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2.7:  llon>preemptible  Tasks 

It  Is  occasionally  necessary  to  perform  all  or  some  subset  of  a  control  structure's 
tasks  In  a  norhpreemptible  mode,  even  though  in  the  latter  case  other  tasks  at  that 
priority  level  may  be  preemptible.  Simply  indicating  that  a  task  is  non-preemptible 
is  equivalent  to  saying  that  the  interrupt  system  is  "turned  off"  while  that  task  is 
in  execution.  For  generality,  the  notation  allows  as  an  alternative  the  specification 
of  exactly  those  events  which  are  not  allowed  to  interrupt  the  task.  Both  capabili¬ 
ties  are  provided  with  the  augmented  syntax,  shown  in  Figure  2.13.  The  scope  of 
the  symbol  for  non-preemptibility  extends  to  closed  control  structures  in  the  natural 
way,  I.e.  every  task  in  the  closed  cs  Is  non-preemptible. 

<basic  C8>  <task>  |  <baslc  cs>  6  <task> 

<task>  ::B  <task  ld>  |  <non-preemptibie  tid> 

<norhpreemptible  tid>  '<task>  |  '(<ev  iist>)<task> 

<ev  list>  ::s  <event  var>  |  <ev  llst>,<event  var> 

<non-preemptible  closed  C8>  ::s  *<closed  cs>  |  '(<ev  list»<closed  cs> 
<clo8ed  cs>  ...(same  as  before  plus:  )...  |  <rK>n-preemptible  closed  cs> 

Fig.  2.13.  Syntax  for  non-preemptible  tasks. 

Prefixing  a  task  Id  (or  a  closed  cs)  with  an  apostrophe  (e.g.  'A)  indicates  that  that 
task  Is  not  preemptible  by  any  event.  If  there  is  an  event  list  after  the  apostrophe 
(e.g.  *(e1)A),  then  that  task  is  not  preemptible  by  any  event  in  the  event  list. 
Furthermore,  it  Is  not  preemptible  by  any  event  which  could  lead  to  preemption  by 
an  event  In  the  event  list.  For  example: 
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(((((A»/«iy(oa)B  C)/e2)D/e3)E)* 

Here  If  LC  is  at  B,  it  is  not  preemptible  by  e3  or  e2,  since  e2  initiates  D  which  is 
preemptible  by  e3. 

Algorithm  2.2  can  still  be  used  to  determine  the  nominal  preemption  structure 
for  the  control  structure's  set  of  basic  cs’s.  However,  the  output  of  Algorithm  2.2 
must  then  be  modified  by  removing  preemptibiiity  relations  as  specified. 


2.8i  Stopping  the  Flow  of  Control 

Although  the  emphasis  has  been  on  how  LC  moves  within  a  control  structure, 
there  may  well  be  times  when  there  Is  simply  no  work  to  be  done  for  the  moment. 
It  is  worth  pointing  out  how  the  existing  notation  Indicates  this  with  some  exam¬ 
ples. 

Basically  LC  will  halt  when  It  either: 

1 .  Reaches  the  "end"  of  a  control  structure,  and  finds  no  or 

2.  Reaches  a  slash  C/*)  beyond  which  no  events  (which  are  ca¬ 
pable  of  Interrupting  the  control  structure  to  the  left  of  the  slash) 
have  occurred. 


Several  examples  are  given  in  Figure  2.14  to  clarify  this  concept;  for  conciseness, 
a  typical  (but  not  unique)  task  string  which  may  be  generated  by  each  control 
structure  Is  given.  Additional  notation  should  be  self-explanatory. 
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((A«/e1)B)*  — >  A  A  A  el  B  A  A  A  el  B  ... 

((A/e1)B)*  — >  A  (wait)  e1  B  A  (wait)  e1  B  ... 

((A-/e1)B) - >  A  A  A  el  B  (halt) 

(((A"/e1)B)/e2)"  — >  A  A  A  el  B  (wait)  e2  A  A  A  ... 

Fig.  2.14.  Examples  of  processor  idling. 


2.B.1:  Breaks  in  Event  Coupled  Lists 

In  light  of  the  interpretation  gi^Rs4gconstruc^.<w1f!ch  result  in  stopping  the 
flow  of  control,  it  will  be  noted  that  there  is  no  way  to  apply  iteration  to  a  portion 
of  the  control  structure  which  Includes  all  of  a  lower  priority  control  structure  and 
part  of  an  event  coupled  list.  What  Is  needed  is  the  concept  of  a  bretak,  which  is 
essentially  a  restricted  “go  to"  statement;  It  directs  LC  to  Jump  over  the  rest  of 
the  event  coupled  list  to  the  right  parenthesis  matching  the  Initial  left  parenthesis 
of  the  event  coupled  list.  Thus  It  enables  the  iteration  at  the  end  of  the  event 
coupled  list  to  be  applied  to  any  intermediate  part  of  the  list  as  needed.  The  syn¬ 
tax  for  a  break  Is  the  up-arrow  (t)  at  the  point  where  the  break  Is  desired;  It  al- 
wcys  follows  a  basic  control  structure,  sc  It  can  be  incorporated  Into  that  BNF: 


Kbasic  cs>  <task>  |  <basic  cs>  |l  <task>  |  <basic  cs>  t 

As  an  example,  consider  the  control  structure  of  Example  2.2  modifled  to  Include 
two  breaks: 


(A/(e1:((Bt/e2)C)|e3:((DT/e4)E)))" 
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Now,  when  LC  reaches  the  end  of  B  or  D.  It  returns  to  A  instead  of  waiting  for  e2 
or  e4,  respectively. 


2.9:  External  Termination  of  a  Control  Structure 
Consider  the  control  structure: 

Example  2.3.  ((((A*/e1)B*)/e2)C)* 

Since  B*  is  non>terminating  and  runs  at  a  higher  priority  than  A”,  A  wlli  never  be  ex¬ 
ecuted  again  once  el  occurs.^  There  is  nothing  wrong  with  this  per  se,  but  with 
the  given  notation  It  is  not  possible  to  represent  the  case  where  occurrence  of  e2 
aborts  the  repetition  of  B,  and  returns  control  to  A*  after  executing  C  rather  than 
to  B*. 

To  do  this,  the  notation  must  be  able  to  indicate  that  occurrence  of  an  event 
terminates  execution  of  a  particular  control  structure,  and  thus  LC  does  not  return 
to  that  control  structure  until  its  initiating  event  occurs  again.  The  modified  syn¬ 
tax: 

<task>  <task  id>  |  <non-preemptibte  tld>  |  <abort  tid> 

<abort  tld>  B<task>  ]  9(<ev  Ii8t»<task> 

<al)ort  C8>  B<closed  cs>  |  9«ev  list»<clo8ed  cs> 

<elosed  cs>  ...(same  as  before  plus:  )...  |  <abort  cs> 

Thus  It  can  be  specified  that  any  event  aborts  a  task  (e.g.  8B)  or  set  of  tasks 

1.  Recall  that  an  event  "flag,"  In  this  case  el,  is  rwt  turned  off  until  the  end  of 
the  control  structure  which  its  occurrence  initiates.  B"  has  no  end. 
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(e.g.  9(A  B  O)  or  that  any  set  of  events  causes  termination  (e.g.  8(e2)B).  The 
event  which  aborts  the  taslt(s)  need  not  be  the  same  as  the  one  which  causes 
preemption  in  a  particular  case;  execution  is  terminated  as  long  as  the  aborting 
event  occurs  sometime  after  preemption  and  before  LC  returns  to  the  task. 

If  the  control  structure  of  Example  2.3  is  changed  to  make  B  an  <abort  tid>, 
the  desired  behavior  is  obtained: 

((((A»/e1  )0(e2)B«)/e2)C)'‘ 

Now  the  string  *A  A  A  el  B  B  B  e2  C  A  A  A  ...*  can  be  generated,  where  repetition 
of  A  and  B  is  for  an  arbitrary  number  of  times. 


2.10:  Return  of  Control  to  a  Preempted  Task 

There  are  two  distinct  choices  of  what  to  do  when  LC  returns  to  a  task  which 
was  interrupted  during  its  execution:  either  resume  execution  from  where  it  ieft 
off,  or  start  over  again  from  the  beginning  of  the  task.  These  two  strategies  will 
be  referred  to  as  resumption  and  restarting  respectively.  Each  strategy  has  Its 
advantages  and  may  be  the 'best  choice  in  different  situations.  A  task  which  Is  irb 
terrupted  often  enough  may  never  complete  if  it  Is  always  restarted  from  the  begin¬ 
ning.  On  the  other  hand,  in  a  process  control  situation  the  inputs  to  an  interrupted 
task  may  have  changed  radically  since  It  was  preempted,  and  resuming  the  compu¬ 
tation  started  with  the  old  Inputs  may  lead  to  anachronistic  outputs  which  are  not 
relevant  to  the  current  control  situation.  Therefore,  it  Is  desirable  to  incorporate 
mearw  of  representing  both  strategies  In  the  notation.  For  complete  generality.  It 
muat  be  capable  of  handling  a  situation  where  two  different  tasks  in  the  same  coib 
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•ral  slmetitre  aiay  follow  the  two  different  strategies.  Furthermore,  it  is  necessary 
Ilf  fmmmm/km  itm  point  of  interruption  In  the  case  of  resumption,  so  the  processor 

wN  knew  w»e«e  «»  immmm  mumctMoit. 

When  the  proMeai  o*  rmatm/ting  a  control  structure  Is  examined  carefully,  it  is 
seen  that  there  are  reeky  two  sub  '  s«e*  s»b«cb  are  of  interest.  First  it  must  be 
recognized  that  the  actual  unit  which  is  reetsrt**!  ,s  issk  At  the  next  higher 
level,  a  task  appears  In  a  control  structure  as  pert  of  s  bosir  •.antral  structure. 
Thus  the  problem  is  really  how  to  restart  a  <basic  cs>.  If  there  ts  an«y  '■»«>  is«k  m 
the  <baslc  cs>,  the  problem  Is  easily  soived-simply  restart  that  task.  If  thor«i 
more  than  one  task  In  the  <basic  cs>,  then  the  entire  <basic  cs>  could  be  restart' 
ad  from  the  beginning  of  its  first  task,  or  it  could  be  restarted  from  the  beginning 
of  the  task  which  was  partially  finished  when  the  preemption  occurred.  For  exam¬ 
ple,  consider  the  following  control  structure: 

(((A  B)«/e1)C  D)* 

If  event  el  occurs,  and  C  0  executes,  (A  B)"  must  be  restarted  (or  resumed). 
Here  are  the  possibilities; 

1.  Resume  from  the  point  of  Interruption,  in  either  A  or  B. 

2.  Restart  from  the  beginning  of  A. 

3.  Restart  at  the  beginning  of  A  if  LC  was  at  A  when  el  oc¬ 
curred:  restart  at  the  beginning  of  B  if  LC  was  at  B  when  el  oc¬ 
curred. 

The  first  case  will  be  the  default  case,  and  Is  assumed  for  all  basic  control  struc¬ 
tures  as  they  have  been  so  far  defined.  The  second  case  will  be  called  g/oba/ 
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restart;  the  third  case  local  restart.  If  a  syntax  Is  defined  for  the  concept  of  glo¬ 
bal  restart,  it  can  be  used  to  synthesize  local  restart  as  a  special  case.  Thus  a 
syntax  will  be  given  called  "restart  cs",  and  It  will  have  semantics  of  "global  res¬ 
tart",  the  second  case  above. 

<re8tart  cs>  ::a  >  <ba8lc  cs> 

To  control  the  scope  of  the  restart  symbol,  restart  control  structures  are  intro¬ 
duced  into  other  control  structures  strictly  through  their  appearance  in  closed  con¬ 
trol  structures: 

<closed  C8>  (  <baslc  cs>  )  |  (  <preemptlble  cs>  )  | 

(  <closed  C8>  <preefflptible  cs>  )  |  (  <closed  cs>  <basic  cs>  )  | 

(  <closed  cs  list>  )  I  (  <restart  cs>  ) 

tSere  is  an  exempie  of  a  control  structure  containing  restarts: 

((((>A  BXC  D)((>E)(>F)))/e1)G)« 

Execution  of  tMe  oewtrei  strMc««ire  prereeds  MenttoeNy  to  that  of  the  basic  control 
structure  (A  B  C  0  E  f)  unM  event  e  i  eaese^e  tMe  caueee  execution  of  G;  after 
G  completes: 

1.  If  LC  was  at  A  or  B  when  el  happened,  LC  reteme  nm  e* 
ginning  of  A  (global  restart  of  (>A  B)). 

2.  If  LC  was  at  C  or  D  when  e1  happened,  LC  resumes  froai  the 
point  of  interruption  in  either  C  or  0. 

3.  If  LC  was  at  E  or  F  when  el  happened,  LC  returns  to  the  be¬ 
ginning  of  E  or  F  respectively  (note  that  local  restart  of  (E  F)  is 
equivalent  to  ((>E)(>F))). 
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2.10.1:  Conditional  Restart  of  a  Control  Structure 

There  le  another  possibility  which  should  be  represented.  In  some  instances,  a 
task  should  be  restarted  if  it  was  preempted  by  one  event  (or  one  of  a  set  of 
events),  but  resumed  if  It  was  preempted  by  another.  This  Is  handled  by  explicitly 
listing  the  events  which  would  cause  restart  of  a  task.  Thus  a  restart  cs  without 
an  event  list  is  unconditionally  restarted,  while  one  with  an  event  list  is  only  res¬ 
tarted  if  an  event  in  its  event  list  occurred  since  it  was  last  run.^ 

<rastart  cs>  ;:=  >  <basic  cs>  |  >  «ev  list»  <basic  cs> 

Example: 

(((((>(e2)A)*/e1  )(>B))*/e2)C)« 

Here  A  is  restarted  If  either 

1.  A  is  preempted  by  e2  or 

2.  A  Is  preempted  by  e1,  which  starts  B.  B  Is  then  preempted  by 
e2  before  completion. 

B  Is  unconditionally  restarted,  and  A  is  resumed  if  e2  does  not  occur  between  the 
time  of  A's  preemption  by  el  and  the  resumption  of  A. 


1.  Note  that  this  means  that  the  restart  causing  event  need  not  be  the  one  which 
caused  the  task’s  preemption;  there  may  have  been  a  chain  of  preemptions  which 
Included  the  restart  causing  event,  and  this  is  deemed  sufllcient  cause  for  restart. 
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2.11:  Codestripping 

A  time>sliced  allocation  of  processor  time  can  be  represented  with  the  existing 

4»> 

notation  by  letting  the  event  variables  stand  for  timer-generated  interrupts.  One 
additional  form  of  preemption  which  will  be  explicitly  represented  here  is  codestrip¬ 
ping,  as  outlined  In  Section  1.1. 

In  codestripping,  calls  to  the  operating  system  are  inserted  into  a  task  by  the 
compiler  at  calculated  intervals,  resulting  In  preemption  of  the  task  when  they  are 
executed.  The  syntax  Is  as  follows: 

<codestripped  cs>  ::s  <baslc  cs>  /  <integer> 

<preemptlble  cs>  <control  structure>  /  <event  list>  |  <codestripped  cs> 

Thus  codestripped  control  structures  are  introduced  into  other  control  structures 
under  the  same  syntax  as  preemptible  control  structures.  An  example  of  a  codes¬ 
tripped  control  structure; 

((A  B/6)C)« 

The  meaning  here  is  that  the  basic  control  structure  A  B  is  executed  1  /5  at  a  time, 
based  on  its  total  (estimated)  execution  time;  it  is  then  preempted  and  C  Is  exe¬ 
cuted.  When  C  finishes,  LC  returns  to  the  point  of  preemption,  and  executes 
another  1/6  of  the  way  through  A  B  (whether  this  Is  actually  In  A  or  In  B  depends 
of  course  on  their  relative  lengths).  Thus  C  will  be  executed  five  tiroes  for  every 
single  execution  of  A  B. 

Notice  that  control  structures  such  as  (>A  B/10)  are  syntactically  illegal;  the 
notion  of  globally  restarting  (or  locally  restarting,  for  that  matter)  A  B  is  incompati- 
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ble  with  the  semantics  of  codestripping.  Furthermore,  codestripping  of  closed  con¬ 
trol  structures  could  lead  to  highly  ambiguous  or  meaningless  structures  and  is 
disallowed.  This  prevents  such  structures  as  ((A  B/5)/10)  and  (((A  B”/e1)C)/5). 
Structures  which  execute  until  they  either  finish  a  codestrIp  or  are  interrupted  by 
an  event  are  allowed,  as  they  should  be,  e.g.  (((A  B/6)/e1)C)*'  which  executes  C 
for  every  1/6  of  A  B  executed  and  whenever  el  happens. 


St  R«pres«ntational  Powar  of  tha  Notatioii 


S.lt  Introduction 

This  chapter  presents  a  catalog  of  control  structure  types  which  the  notation 
of  the  preceding  chapter  is  capable  of  representing.  It  is  not  claimed  that  every 
conceivable  type  of  representable  control  structure  is  included,  but  the  list  at* 
tempts  to  be  comprehensive  as  to  general  forms.  Some  examples  are  also  given  of 
types  of  control  structures  which  are  not  representable. 


8.2:  Control  Flow  Graphs 

Control  structures  can  be  conveniently  categorized  by  the  topology  of  their 
Control  Flow  Graphs,  or  CFG’s.  A  CFG  is  a  directed  graph;  more  precisely,  It  is  a 
set  of  nodes  and  directed  arcs,  where  a  node  represents  a  basic  cs  and  an  arc 
represents  the  movement  of  LC  between  two  nodes.  The  nodes  bear  the  names  of 
the  basic  cs's  which  they  represent. 

Consider  an  arc  A  which  originates  at  basic  cs  o  and  has  as  a  destination 
basic  cs  d.  If  o  occurs  to  the  left  of  d  In  the  control  structure,  then  arc  A  is  a 
forward  arc;  otherwise,  it  is  a  backward  or  back  arc.  Either  type  of  arc  may  bear 
labels: 

1.  An  arc  which  represents  the  uninterrupted  flow  of  control  due 

to  termination  of  a  basic  cs  is  a  forward  arc,  and  is  untabelled. 

Note  that  this  Includes  breaks  as  detailed  in  Section  2.8.1. 

2.  An  arc  which  represents  the  flow  of  control  due  to  preemption 
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by  an  event  occurring  Is  a  forward  arc  (an  event  arc)  and  is  la¬ 
belled  «vith  the  corresponding  event  variable. 

3.  An  arc  which  represents  the  flow  of  control  due  to  iteration  is 
a  back  arc  and  is  labeiled  with  an 

It  may  seem  that  tasks  rather  than  basic  cs’s  should  be  at  the  nodes  of  CFG's, 
and  in  fact  the  algorithms  used  for  determining  real-time  latencies  must  sometimes 
deal  with  controi  flow  at  the  task  level.  However,  this  additional  detail  adds  noth¬ 
ing  to  the  breadth  of  representable  control  structure  types,  and  in  fact  detracts 
from  the  readability  of  the  CFG’s.  ^ 

Figure  3.1  gives  an  example  of  the  CFG  for  a  simple  control  structure. 


A  B - el - *C 

\ _ _ _ I 


Fig.  3.1.  CFG  for  ((A  B)/e1)C)«. 

A  string  naming  the  tasks  and  (optionally)  the  events  encountered  in  a  path  taken 
by  LC  through  a  CFG  Is  called  an  execution  of  the  corresponding  control  structure. 
A  B  el  CAB  and  A  el  C  A  el  C  are  both  executions  of  the  above  cs. 


1.  If,  for  example,  a  basic  cs  is  preemptible  by  event  e/,  then  every  task  in  the 
basic  cs  would  have  a  forward  arc  labelled  e/. 
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3.2,1:  Priority  Levels 

As  an  extra  benefit,  the  CFG  notation  provides  a  convenient  mechanism  for  for¬ 
malizing  the  concept  of  priority  level,  which  has  been  used  somewhat  intuitively 
thus  far.  To  find  the  priority  level  of  basic  cs  /,  do  the  following: 


1.  Let  the  leftmost  basic  cs  In  the  control  structure  have  priority 
0  by  definition. 

2.  Find  the  acyclic  path  from  the  priority  0  basic  cs  to  basic  cs  / 
having  the  largest  number  of  event  arcs. 

3.  The  priority  of  basic  cs  /  is  equal  to  the  number  of  event  arcs 
in  this  path. 


3.3:  Interrupt  Driven  Control  Structures 

The  CFG’s  for  control  structures  using  only  sequencing  and  Iteration  are  fairly 
straightforward  and  do  not  expand  the  catalog  of  representable  control  structures 
by  much.  The  sequence  of  tasks  within  a  basic  cs  Is  implicitly  represented,  and 
forward  control  flow  from  one  basic  cs  to  another  simply  translates  to  an  unlabelled 
arc  in  the  CFG. 

The  more  Interesting  CFG's  are  those  which  are  derived  from  control  structures 
having  event  variables.  It  is  readily  apparent  ttiat  the  notation  has  considerably 
more  flexibility  than  that  which  is  needed  for  representing  traditional  priority  inter¬ 
rupt  schemes.  This  flexibility  is  derived  principally  through  the  placement  of  the 
iteration  character  and  by  use  of  the  branching  Introduced  by  event  coupled 
Hats.  The  latter  has  been  mentioned  briefly;  the  former  bears  clarification. 

A  back  arc  can  be  originated  from  any  basic  cs  by  following  It  with  an 
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However,  there  Is  a  degree  of  freedom  in  specifying  the  destination  of  the  back 
arc;  this  will  be  exercised  In  enlarging  the  catalog  of  control  structures.  Funda¬ 
mentally,  the  back  arc  may  return  to  the  same  priority  level,  a  lower  one,  or  the 
lowest  one.  If  it  does  not  return  to  the  lowest  level,  a  certain  "shrinkage"  In  the 
future  range  of  LC  is  experienced.  This  will  be  elaborated  on  shortly.  Additional 
variations  on  the  fundamental  types  are  achieved  through  use  of  the  interrupt  mask 
(norhpreemptlble  tid),  external  abort  and  restart/resume  capabilities. 


8.3. It  Globally  Cyclic  Control  Structures 

Under  this  category  is  included  all  control  structures  with  CFG's  such  that 
every  back  arc,  regardless  of  Its  originating  priority  level,  goes  to  the  first  task  of 
the  lowest  priority  level.  Informally,  this  means  that  upon  completion  of  the  tasks 
at  a  given  priority  level,  the  processor  will  scan  all  the  event  variables  In  the  con¬ 
trol  structure  from  the  lowest  level  to  the  highest,  and  begin  execution  of  the 
highest  level  task  pending.  This  is  as  opposed  to  control  structures  with  local  cy¬ 
cles,  where  the  lower  priority  events  are  not  necessarily  considered  in  each  such 
situation. 

The  traditional  interrupt  systems  available  on  most  processors  fall  into  this 
category;  such  systems  are  further  subdivided  Into  two  types,  which  are  called 
here  the  uveak  priority  system  and  the  strong  priority  system,  in  the  weak  priority 
system,  although  arbitration  between  interrupts  from  two  or  more  events  is  provid¬ 
ed,  there  Is  actually  only  a  single  true  level  of  interruption.  There  Is  a  "user"  or 
"main"  program  which  runs  at  the  lower  priority,  and  any  number  of  events  may 
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each  preempt  it;  however,  no  event  may  interrupt  any  task  which  gained  control  it¬ 
self  via  an  Interrupt.  This  type  of  control  structure  is  represented  using  event 
coupled  lists,  as  in  Example  3.1. 

Examplo  8.1.  (MAIN/(e1:  A|e2:  B|e3:  C))* 

The  CFG  (Figure  3.2)  has  an  interrupt  branch  from  "main”  for  every  interrupting 
event,  to  the  basic  cs  it  initiates.  Completion  of  A,  B  or  C  forces  LC  to  return  to 
MAIN,  so  there  is  a  back  arc  from  each  of  them.  For  the  sake  of  keeping  the  CFG’s 
readable,  multiple  back  arcs  with  the  same  destinations  will  be  combined,  as  is 
done  In  Figure  3.2.  It  is  worth  keeping  in  mind,  however,  that  this  does  not  imply 
that  anothef  type  of  node  (Junction)  has  been  added. 


Fig.  8.2.  CFG  for  Example  3.1. 

A  strong  priority  system  supports  a  processor  priority;  the  currently  running 
task  has  a  priority  n  associated  with  it,  and  any  events  interrupting  with  priority  m 
>  ff  may  preempt  it.  With  the  exception  of  Bie  ability  provided  for  masking  inter¬ 
rupts,  the  processor  runs  the  Mghest  priority  task  waiting  for  service  at  any  time. 
Thia  type  of  multiple  priority  level  Interrupt  syatem  is  repreaented  by  strict  nesting 
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of  preemptible  (and  Iterative)  control  structures,  as  shown  in  Example  3.2. 


Exahiple  3.2.  ((((A"/e1)B)"/e2)C)* 


The  general  form  can  be  recursively  constructed;  each  'Mayer*'  looks  like: 

(«iterative  cs>/<event  var»<basic  cs»* 

which  is  itself  an  iterative  cs.  The  <basic  cs>  runs  at  the  next  higher  priority  than 
the  rightmost  basic  cs  In  the  <preemptible  cs>. 

A  CFG  for  Example  3.2  Is  given  In  Figure  3.3;  it  can  be  seen  that  the  proper¬ 
ties  of  nested  interrupt  systems  have  natural  analogues  in  the  graph: 


1.  Let  a  and  fi  be  basic  cs*s  in  the  CFG.  If  there  is  an  acyclic 
path  from  a  to  0  whose  last  arc  is  labelled  ei,  then  there  is  an 
arc  from  a  to  ^  labelled  el.  This  property  stems  from  the  transi¬ 
tivity  of  interruption  in  a  nested,  multiple  priority  system. 

2.  There  is  a  back  arc  from  the  last  basic  cs  at  each  priority  lev¬ 
el  to  the  beginning  of  the  lowest  priority  basic  cs.  After  comple¬ 
tion  of  the  control  structure  at  a  given  priority  level,  LC  returns  to 
the  highest  level  with  a  pending  request. 


Pig.  3.3.  CFG  for  Example  3.2. 


I 
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3.3.2:  Acyclic  Control  Structures 

At  the  other  end  of  the  spectrum  are  found  control  structures  with  no  back 
arcs;  these  represent  completely  non-iterative  systems  where  the  flow  of  control 
terminates  when  It  reaches  the  end  of  any  path.  Such  control  structures  are  furth¬ 
er  subdivided  into  two  types: 

1.  Linear  control  structures  *  control  flow  is  straight-line  and  thus 
entirely  predetermined,  as  In  the  example  of  Figure  3.4. 

2.  Branched  control  structures  •  real-time  decisions  based  on 
event  occurrences  determine  the  actual  flow  of  control;  see  Fig¬ 
ure  3.6.,  which  provides  an  example. 

The  subject  of  linear  control  structures  does  not  leave  much  room  for  discussion 
and  Is  Included  mainly  for  completeness.  However,  there  are  some  interesting  ob¬ 
servations  that  can  be  made  about  branched  control  structures  representable  with 
the  notation,  and  which  apply  Independently  of  whether  there  are  cycles  present; 
these  will  be  considered  in  the  following  section. 


-eV 


C- 


Fig.  3.4.  CFG  for  the  control  structure  ((A/e1)(B  C)D). 
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Fig.  3.6.  CFG  for  the  control  structure  (A/(e1:(B/(e2:C|e3:D))|e4:E)). 


8.3.2. 1:  Branched  Control  Structures 

It  Is  interesting  to  note  that  while  tree-shaped  CFG’s  such  as  the  one  In  Figure 
3.6  can  be  represented,  allowing  arbitrary  tree-shaped  interrupt  structures  is  not 
compatible  with  the  transitivity  of  interruption.  In  fact,  the  notation  cannot 
represent  any  tree  of  depth  greater  than  one  where  the  forward  arcs  are  all  event 
arcs.  Thus  a  CFG  such  as  the  one  In  Figure  3.7  has  no  corresponding  control  struc¬ 
ture. 


Rg.  3.6.  A  tree-shaped  CFG,  for  (A/(e1;B|e2:C)). 

For  example,  consider  an  attempt  to  derive  a  control  structure  for  the  CFG  in 
Rgure  3.7,  a  tree  with  a  depth  of  2.  By  Algorithm  2.2,  It  is  found  that  since  C  in¬ 
terrupts  B  and  B  interrupts  A,  C  must  also  interrupt  A.  Thus  an  arc  labelled  e2 
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must  be  added  from  A  to  C,  and  the  tree  structure  Is  lost.  Event  e2  (and  e3)  can 
be  masked  from  interrupting  A;  but  then  el  is  also  masked,  since  it  initiates  B 
which  is  interruptible  by  e2.  This  same  line  of  reasoning  applies  to  any  other  at¬ 
tempt  to  produce  a  tree-shaped  control  structure  of  depth  greater  than  1 . 


Fig.  a.7.  A  CFG  which  has  no  corresponding  control  structure. 

Essentially,  this  restriction  says  that  there  cannot  be  control  structures  which 
have  completely  local  preemption  structures,  and  yet  at  the  same  time  be  initiated 
by  some  event.  To  Incorporate  this  type  of  structure  would  require  a  notion  of  "lo¬ 
cal”  and  "global"  events,  with  suitable  restrictions  on  their  scope.  The  additional 
complexity  this  would  introduce  may  be  Incompatible  with  the  attempt  to  keep  the 
notation  concise,  but  this  may  be  a  logical  extension  of  the  language  for  some  ap¬ 
plications. 

Although  It  does  not  represent  a  preemption  structure,  Figure  3.B  shows  a  CFG 
which  Is  similar  to  that  of  Figure  3.7,  but  which  is  representable,  and  by  the  follow- 
Ing  control  structure: 

CA  B/(e1:C  ie2:  0}} 

The  arc  from  A  to  B  represents  control  flow  on  termination  of  A,  but  A  cannot  be  in¬ 
terrupted. 
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A - H 


,e2 - *C 


'^eS - iD 


Flo.  3.8.  A  representable  tree-shaped  CFG. 


3.3.3:  Locally  Cyclic  Control  Structures 

Included  In  this  class  are  all  those  control  structures  having  back  arcs  which 
do  not  return  LC  to  the  lowest  priority  level  task.  This  group  Is  further  subdivided 
Into  structures  which  never  return  control  to  the  lowest  priority  task,  and  those 
which  may  or  may  not  make  the  return  at  some  point.  While  the  emphasis  here  is 
on  returning  to  the  lowest  priority  level,  the  same  sort  of  distinctions  can  be  made 
about  any  priority  level  and  its  superiors.  Examples  of  each  case  will  be  given. 


3.3.3.1 1  Dynamically  Decreasing  the  Range  of  LC 

Consider  the  following  general  form  of  control  structure: 

Example  3.3.  (  ...  <preemptible  caXclosed  cs>”/<event  var>  ...  )* 

This  has  a  norhterminating  "<closed  cs>”"  construction,  which  corresponds  to  a 
back  arc  In  the  CFG  from  the  end  to  the  beginning  of  the  closed  cs.  Although  the 
rightmost  forces  LC  to  return  to  the  beginning  of  the  control  structure  (If  the 
”””  ia  reached),  the  <preemptlble  cs>  will  not  be  resumed  since  the  following 
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<closed  cs>  runs  at  a  higher  priority,  and  Is  non-terminating. 

Figure  3.9  gives  the  CFG  for  the  control  structure: 

Example  3.4.  (((A/e1)(B  C)”/e2}D)’* 

which  has  the  above  general  form.  It  can  be  seen  that  once  a  non-terminating  loop 
Is  entered,  although  it  may  be  preempted  by  higher  priority  tasks  (either  momentari¬ 
ly  or  permanently),  control  will  not  return  to  any  task  to  its  left.  Thus  the  control 
structure  has  effectively  "shrunk",  in  that  certain  tasks  are  no  longer  executable. 
This  shrinking  may  occur  in  stages.  If  there  are  several  events  which  Initiate  itera¬ 
tive  control  structures,  and  which  occur  in  succession;  or  it  may  occur  all  at  once, 
if  the  rightmost  such  event  occurs  first. 


Fig.  3.9.  CFG  for  Example  3.4. 


3.3.3.2:  External  Termination  of  Local  Cycles 

A  local  cycle  need  not  always  Indicate  a  decreasing  control  structure.  If  the 
"Cabort  cs>"  construction  Is  used,  then  control  may  reside  for  an  arbitrarily  long 
time  in  a  given  sub-structure  (local  cycle),  and  Anally  return  to  lower  priority  levels 
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wrhan  the  aborting  event  occurs.  The  control  structure  of  Example  3.4  can  be 
modified  by  the  addition  of  a  single  "8“  symbol: 

Example  3.6.  (((A/e1)fi(B  C)Ve2)D)” 

Now  when  e2  occurs,  It  "shuts  off"  el  as  well  as  Initiating  D.  This  is  a  dynamic 
behavior  and  as  such  Is  not  well  suited  to  representation  by  a  CFG;  however  the 
reahtime  latency  algorithms  must  certainly  take  account  of  it. 


3.3.3.31  Restrictions  on  Local  Cycles 

A  back  arc  can  be  formed  from  the  end  to  the  beginning  of  any  closed  control 
structure,  and  hence  there  is  little  restriction  on  its  range  of  possible  destinations. 
One  notable  exception  occurs  in  the  presence  of  event  coupled  lists.  Figure  3.10 
gives  a  CFG  which  does  not  have  a  corresponding  control  structure;  its  illegality  is 
the  presence  of  a  back  arc  which  cuts  across  the  "|"  syntactic  boundary  in  an 
event  coupled  list. 
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Essentially,  this  says  that  the  forking  caused  by  event  coupled  lists  forms  two 
or  more  independent  sub-control  structures,  and  LC  cannot  move  freely  from  one  to 
the  other.  However,  It  is  possible  that  an  event  external  to  all  the  branches  may 
preempt  any  of  them;  thus  a  CFG  Identical  to  that  of  Figure  3.10,  except  that  it 
has  no  back  arc,  corresponds  to  the  legal  control  structure: 

(((A/(e1;  B|e2:  C))/e3)D) 


3.4:  CFGs  at  the  Task  Level 

There  are  several  variations  on  the  general  classifications  presented  here 
urMch  arise  principally  when  control  flow  at  the  inter-task  level  is  considered.  As 
previously  mentioned,  the  complexity  of  the  resulting  CFG's  limits  their  usefulness. 
Thus  these  variations  are  more  suitably  discussed  In  the  context  of  latency  algo¬ 
rithms;  furthermore,  they  do  not  irrtroduce  new  general  classes  of  control  structure 
types  as  far  as  the  topology  of  their  CFGs  Is  concerned,  but  instead  result  in  per¬ 
turbations  of  those  already  considered. 

However,  K  is  reasonable  to  examine  the  changes  which  would  be  induced  on  a 
CFG  which  has  single  tasks  at  Its  nodes,  rather  than  basic  cs’s.  Use  of  the  "<non- 
preemptlble  closed  cs>"  or  "<non-preemptible  tid>''  constructions  results  In  the  re¬ 
moval  of  the  appropriate  event  arcs.  In  addition,  if  the  task  immediately  prior  to 
the  "/<event  var>"  construction  is  masked,  an  unlabelled  forward  arc  is  added  to 
show  the  flow  of  control  which  occurs  on  termination  of  the  masked  task. 

The  default  mode  of  control  return  to  a  preempted  task  is  resumption,  as  dis- 
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cussed  In  Chapter  2.  Thus  any  arc  (backward  or  forward)  to  a  preemptible  cs  of 
this  type  must  be  dynamically  relocated  to  point  to  the  task  which  was  in  execu* 
tion  when  preemption  occurred.  Again,  this  is  not  easily  representable  with  a  static 
CFG,  and  in  fact  corresponds  to  the  need  to  store  some  "state”  Information  while  a 
task  is  dormant. 

If  a  task  Is  to  be  restarted,  this  problem  does  not  arise;  in  fact,  if  an  entire 
closed  cs  Is  of  restart  type,  there  will  be  no  arcs  pointing  to  tasks  internal  to  the 
closed  cs  which  originate  outside  of  it.  The  only  entry  point  from  the  external 
^world’s  point  of  view  is  the  beginning  of  the  Initial  task. 
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4:  R«al-tlm«  Proparti**  of  Control  Structura* 


4.1:  Introduction 

A  primary  motivation  behind  developing  the  language  pruaanted  In  Chapter  2  is 
to  provide  a  representation  of  control  structures  suitable  for  use  as  an  analytical 
tool.  Specifically,  it  provides  a  convenient  format  for  conveying  preemption  and 
control  flow  information  to  an  algorithm  which  then  determines  real-time  properties 
of  the  given  control  structure. 

The  algorithms  to  be  given  here  are  not  intended  to  provide  an  exhaustive 
analysis  of  a  control  structure,  but  rather  to  be  representative  of  the  types  of 
analysis  which  may  be  performed.  The  real-time  properties  measured  here  are  of 
common  Interest:  however,  it  will  probably  be  the  case  that,  depending  on  the 
needs  of  the  particular  user,  different  real-time  properties  may  be  of  special  in¬ 
terest.  In  many  cases,  the  given  algorithms  can  be  adapted  for  measuring  different 
intervals  with  minimal  changes.  In  other  cases  totally  new  algorithms  may  be  need¬ 
ed,  but  parts  of  those  given  will  still  be  useful. 

Much  of  the  terminology  used  here  was  developed  in  [Teixeira  78]  and  the 
reader  Is  referred  there  for  a  complete  discussion. 

A  principal  ^al  here  will  be  to  develop  algorithms  for  determining  the  worst 
case  latency  of  a  list  of  tasks  in  a  given  control  structure.  Informally,  the  worst 
case  latency  of  a  list  of  tasks  a  (written  l(«))  is  the  longest  time  that  can  elapse 
without  there  being  a  complete  execution  of  each  task  In  the  list  In  the  order 
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given.  The  list  of  tasks  whose  latency  is  being  measured  will  be  referred  to  as  a 
constraint.  The  latency  of  a  constraint  is  measured  with  respect  to  an  execution 
of  a  given  control  structure,  where  an  execution  is  a  list  of  tasks  in  the  order  in 
which  they  are  executed  by  the  CPU  in  a  particular  invocation  of  that  control 
structure.  Each  element  (task  Id)  of  the  execution  has  a  we/g/rt  associated  with 
It,  written  as  |<task  ld>|.  The  weight  represents  an  upper  bound  on  that  task’s 
execution  time  on  a  particular  processor. 

Note  that  depending  on  event  timings,  a  number  of  different  executions  (of 
finite  or  infinite  length)  may  be  generated  by  a  single  control  structure.  Consider 
the  control  structure: 


(((A  B)*/e1)C)« 


(6.1) 


Possible  executions  include: 

A  B  A  B  A  B  ... 

A  B  C  A  B  C  ... 

ABABCABABC... 

among  many  others.  Also  note  that  in  the  case  of  preemption  a  task  may  be 
suspended  and  restarted,  and  thus  partial  weighting  (or  its  effective  equivalent) 
must  be  accounted  for. 

The  weight  of  a  list  of  tasks  is  the  sum  of  their  Individual  weights.  The  worst 
case  latency  of  a  constraint  a  with  respect  to  an  execution  fi.  Is  the  sublist  of  fi 
with  greatest  weight  which  does  not  contain  a.  The  term  "contains"  as  used  here 
means  that  the  elements  of  m  occur  in  order  and  with  their  full  weights;  there  may 
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be  arbitrarily  many  other  tasks  Interleaved.  For  example,  (A  B  C  0)  contains  (A  C) 
as  well  as  (A  B),  but  it  does  not  contain  (C  B). 

The  provision  that  the  tasks  be  Included  with  their  full  weights  is  emphasized 
for  the  following  reason.  In  many  real-time  process  control  applications,  the  inputs 
to  a  task  may  change  at  any  time,  but  the  scheduling  of  task  initiation  may  not  be 
synchronized  with  the  arrival  of  new  inputs.  Thus  it  is  entirely  possible  that  new 
inputs  may  arrive  Immediately  after  the  initiation  of  a  task,  i.e.,  after  It  has  already 
read  the  outdated  Inputs.  Given  this  possibility,  it  may  be  that  nearly  two  complete 
occurrences  of  the  constraint  may  be  executed  in  an  interval  which  still  does  not 
contain  (In  the  strict  sense  defined  above)  a  single  occurrence  of  the  list.  For  ex¬ 
ample,  given  the  control  structure  (A  B  C)”,  consider  the  execution  A  B  C  A  B  C.  If 
an  Input  to  A  arrives  immediately  after  A  reads  its  old  input?  then  it  is  only  after 
the  second  occurrence  of  C  has  completed  its  execution  that  all  the  tasks  in  the 
constraint  will  have  been  executed  in  order  (the  constraint  Is  satisfied  by  such  an 
execution).  Thus  a  way  Is  needed  to  represent  an  execution  whose  end-tasks  are 
weighted  Just  less  than  their  nominal  values;  the  notation  chosen  is  bracketing 
such  a  task  on  its  "short  side";  [A  means  "begin  Just  after  the  start  of  A",  and  C] 
means  "stop  Just  before  the  finish  of  C".  The  weight  of  such  a  task  is  its  nominal 
weight  minus  t,  where  «  is  arbitrarily  small.  Thus  the  worst  case  latency  of  (A  C)  In 
(A  B  O"  is  I  [A  B  C  A  B  C]  |. 

The  list  (A  B  C  A  B  C)  is  an  example  of  a  critical  window  for  (A  C),  where  a 

1.  Unless  It  Is  known  that  the  timings  of  such  data  arrivals  can  be  synchronized 
with  task  Initiation,  it  must  be  assumed  that  this  could  occur  at  any  time  after  A  Is 
Initiated. 
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critical  window  Is  defined  as  a  list  «  such  that  m  contains  two  occurrences  of  a 
constraint  C  but  [a]  contains  no  occurrences  of  C.  In  many  cases  the  worst  case 
latency  of  a  constraint  will  turn  out  to  be  the  weight  of  a  critical  window  (the  most 
cr/t/ca/  window).  The  worst  case  latency  of  a  constraint  with  respect  to  a  control 
structure  (as  opposed  to  an  execution)  Is  taken  over  all  the  possible  executions 
that  may  be  generated  by  the  control  structure  ^  no  matter  what  the  event  timings 
(within  specified  limits),  there  can  be  no  longer  Interval  which  does  not  contain  the 
list.  Thus  part  of  the  problem  faced  Is  to  classify  the  types  of  executions  which 
may  be  generated  by  a  control  structure  and  narrow  the  choice  among  them  for 
finding  the  worst  case,  since  otherwise  the  combinational  explosion  in  the  number 
of  possible  executions  would  make  the  problem  intractable. 


4.2i  Weights  of  Task  Identifiers 

It  was  mentioned  briefly  above  that  a  weight  is  associated  with  every  task 
Identifier,  representing  an  upper  bound  on  its  execution  time.  Naturally  this  must 
be  with  respect  to  a  particular  processor,  but  even  with  this  restriction  there  are 
some  difficulties  In  determining  a  meaningful  upper  bound  on  execution  time.  Aside 
from  Input  dependent  computation  times,  there  are  processor  dependent  variables 
such  as  memory  access  time  in  a  virtual  storage  system.  The  worst  case  time 
would  occur  when  all  memory  references  were  to  the  slowest  storage  device,  but 
the  probability  of  such  a  case  actually  occurring  may  be  nearly  zero.  On  the  other 
hand,  there  may  be  an  uncomfortably  large  variance  associated  with  the  mean  ac¬ 
cess  time  vrtien  critically  time-dependent  processes  are  Involved.  It  seema  than 
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that  in  such  a  case  one  must  either  arrive  at  a  statistically  reasonable  upper  bound 
on  memory  access  time  or  change  the  storage  allocation  parameters  of  time  depen¬ 
dent  tasks  to  ensure  their  residence  at  a  particular  level  or  above  (in  access 
speed)  of  the  storage  hierarchy. 

if  an  upper  bound  on  the  execution  time  for  a  task  does  not  exist,  this  would 
imply  potentially  infinite  worst  case  latencies  and  there  would  be  no  purpose  to  ap¬ 
plying  the  algorithms  given  here.  If  there  is  any  question  of  the  value  of  an  upper 
bound,  then  it  must  be  chosen  carefully  in  light  of  the  particular  application  of  the 
latency  Information.  The  weight  of  each  task  will  be  an  input  to  the  latency  algo¬ 
rithms  along  with  the  control  structure,  and  it  will  be  assumed  that  a  function  (table 
look-up)  exists  which  returns  this  weight  In  response  to  the  notation  |<task  id>|. 


4.3i  Properties  of  Event  Variables 

In  order  to  arrive  at  worst  case  latency  times  for  a  control  structure  containing 
event  variables  It  is  necessary  to  know  something  more  about  the  timing  of  the 
events  represented.  To  illustrate,  consider  the  control  structure: 

(((A  B)-/e1)C  D)«  (6.2) 

If  el  never  occurs,  the  only  possible  execution  of  this  control  structure  is  (A  B  A  B 
A  B  ...).  The  latency  l(A  B)  in  this  case  is  2(|A|*|B|)  -  t,  since  the  longest  sublist 
%rhlch  does  rK>t  contain  A  8  would  be  [A  B  A  B].  On  the  other  hand,  if  el  occurs  at 
leasi:  once  every  |C|+|0|  seconds,  then  l(A  B)  Is  infinite,  since  the  only  execution 
generated  Is  (C  D  C  0  C  0  ...)  (Ignoring  possible  initial  executions  of  A  and  B).  If 
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the  control  structure  contains  more  event  variables  It  may  become  difllcutt  to  deter¬ 
mine  the  worst  case  latency  (the  largest  l(A  B))  by  inspection,  and  the  need  for 
additional  Information  about  the  event  variables  is  clear. 

In  particular,  what  is  needed  is  the  foliowing: 

the  minimum  period  of  event  e^;  It  is  guaranteed 
that  e,  will  not  occur  more  than  once  In  any  interval  of  (e,) 
aeeonds. 

2.  maximum  period  of  event  e^;  It  is  guaranteed 

that  there  will  be  at  least  one  occurrence  of  e^  in  any  interval  of 
v„,,(e,)  seconds. 

It  Is  entirely  plausible  and  Indeed  likely  that  In  some  situations  )  will  be 

the  same  as  ).  This  is  the  case  for  all  regularly  occurring  cyclic  events, 

such  as  data  sampling,  processor  time  slicing,  etc. 

In  general.  It  is  impossible  to  distinguish  a  )  which  is  less  than  the  pro¬ 

cessor  Instruction  cycle  time  from  an  Infinitesimal  one  since  the  processor  could  not 
possibly  respond  to  an  event  which  occurred  at  that  rate  in  any  meaningful  way. 
In  fact,  for  a  reasonable  system,  one  would  have  to  pick  a  (Sy)  considerably 

larger  than  the  Instruction  cycle  time,  but  the  actual  value  urlll  be  application 
dependent.  For  most  events  of  interest  it  will  be  possible  to  determine  a  reason¬ 
ably  tight  ):  ®-0*>  if  the  event  represents  an  I/O  service  request.  It  cannot 

occur  more  often  than  some  time  Interval  dependent  on  the  I/O  device’s  maximum 
character  tranamission  rata. 

Unfortunately,  finding  a  good  value  for  w^^(ey)  is  more  difficult  in  many  cases. 
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An  event  often  represents  an  exceptional  condition,  which  may  never  arise  in  par¬ 
ticular  executions.  Fortunately,  most  control  structures  will  not  put  time  critical 
tasks  in  such  a  position  that  their  Initiation  depends  on  but  rather  it  is 

more  likely  that  the  completion  of  a  constraint  may  be  influenced  by  time  lost  after 
such  an  event  occurs;  and  the  time  lost  will  be  a  function  of  (Sy),  not 

a__,,(e. ).  If  a  good  value  of  e^(e. )  is  not  available  for  a  patticuiar  event,  then 

It  is  more  likely  that  the  interval  of  interest  would  be  the  maximum  time  from  the 
occurrence  of  Sy  to  the  initiation  and/or  completion  of  its  associated  control  struc¬ 
ture,  rather  than  the  longest  time  between  such  executions  (a  latency  value). 


6t  Algorithms 


6.1 1  Introduction 

A  series  of  hierarchicaffy  related  algorithms  will  be  presented  in  this  chapter, 
which  will  be  directed  at  the  problem  of  Aiding  the  worst  case  latency  of  a  con¬ 
straint  with  respect  to  a  given  control  structure.  Each  algorithm  in  the  hierarchy  is 
applicable  to  a  larger  subset  of  the  set  of  all  representable  control  structures,  and 
may  call  upon  the  algorithms  designed  for  solution  of  the  problem  on  a  lesser  sub¬ 
set  as  subroutines. 

The  overhead  due  to  context  switching  is  not  explicitly  taken  into  considera¬ 
tion  here.  It  may  be  accounted  for  by  a  fractional  reduction  of  the  effective  pro¬ 
cessing  power  of  the  CPU,  when  computing  the  worst  case  task  weights.  If  this  is 
not  satisfactory,  then  the  algorithms  could  be  adjusted  so  that  each  event  oc¬ 
currence  and  corresponding  Initiation  Is  counted,  and  the  overhead  due  to  each 
could  be  added  to  the  delays  attributed  to  interruption. 

As  the  worst  case  latency  algorithms  are  developed.  It  will  be  seen  that  the 
determination  of  algorithms  to  measure  several  other  real-time  properties,  interest¬ 
ing  in  their  own  right.  Is  required.  Finally,  special  cases  may  result  in  substantial 
simplification  to  the  algorithms,  and  examples  of  this  effect  are  Included. 
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6.2:  Latencies  in  the  Absence  of  Preemption 

The  first  step  taken  here  toward  the  general  solution  of  the  worst  case  laten¬ 
cy  problem  is  the  development  of  algorithms  to  determine  the  latencies  when  no 
preemption  Is  present,  i.e.  when  there  are  no  event  variables  or  codestrips  in  the 
control  structure.  This  leaves  control  structures  which  generate  finite  and  infinite 
lists  of  tasks,  in  which  all  tasks  execute  to  completion  once  initiated. 

Since  only  non-terminating  Iteration  Is  represented  (In  the  absence  of  preemp¬ 
tion),  ail  finite  lists  must  contain  no  iterative  components.  Furthermore,  any  Unite 
list  L  of  tasks  which  contains  at  least  one  occurrence  of  a  constraint  d  may  be 
broken  down  into  a  series  of  possibly  overlapping  sublists: 

^1*  *1'  *2’  *  ‘  *  **o’  ^2^ 

vdth  respect  to  a  constraint  C  where: 

1.  0^  and  $2  each  contain  one  instance  of  C,  but  f.|]  and  [$2 
contain  no  instances  of  C. 

2.  The  «y’s  are  critical  windows  for  C. 

The  sublist  0^  is  the  head  of  the  list  L  having  minimum  weight  and  which  also 
contains  one  instance  of  C;  02  is  the  tail  with  least  weight  which  contains  one  Irt- 
stance  of  C.  The  list  is  the  critical  window  which  starts  at  the  first  instance  In 
L  of  the  first  task  in  C;  is  the  critical  window  which  starts  at  the  ft/>  instance 
In  L  of  the  first  task  in  C.  If  L  contains  no  critical  window,  there  will  be  no  e^'s; 
1.  If  L  does  not  contain  C,  then  the  latency  of  C  in  L  Is  Infinite. 
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sifflilariy,  if  L  begins  or  ends  with  a  criticai  window  then  or  ^2  respectiveiy  may 
also  be  empty. 

Figure  5.1  gives  an  exampie  of  the  breakdown  for  the  list  (ABCDBCBCE) 
and  the  constraint  (B  C).  Note  the  overlapping  of  the  sublists,  and  that  in  this 
case  |«,|  *  legl- 


ABC 


D 


•1 


B 


C 


BCE 


Fig.  6.1.  Breakdown  of  a  finite  task  list  into  subiists. 


Theorem  6.1.  The  latency  of  a  constraint  C  with  respect  to  a  finite  list  L  which 
contains  at  least  one  occurrence  of  C  Is  the  maximum  weighted  sublist  in 
the  set  of  subiists  {6.|,  Si.  *  *  *  >*/)»  ^2^*  where  the  e^'s  and  fi^’s  are  as 

defined  above. 


Proof.  The  proof  will  be  given  in  two  parts;  first,  by  showing  that  any  list  which 
contains  at  least  one  occurrence  of  C  can  be  broken  down  in  the  above  manner  to 
obtain  such  a  set  of  subiists  which  Includes  all  the  tasks  in  the  original  list;  and 
second,  by  showing  that  no  other  sublist  not  in  the  set  can  have  a  greater  latency 
for  C. 

The  proof  of  the  first  part  Is  given  by  showing  a  method  of  constructing  the 
set  {|>.|.  •2>  ’  ‘  ^2^  given  such  a  list  L  and  a  constraint  C. 

Find  each  sublist  of  L  which  exactly  contains  one  instance  of  C  (i.e.,  a  sublist 
y  such  that  y  contains  C  but  [7  and  y]  do  not  contain  C);  label  each  such  sublist 
7^,  for  /  ■  1  to  n,  where  n  is  the  number  of  instances  of  C  in  L.  The  list  L  can 

thereby  be  considered  as  a  series  of  sublists: 

^1'  ^1'  ^2’  ^2*  *  ’  *  '  ^0-1’  ^n-1’  ^n  (6.2) 
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where  the  #^’s  do  not  contain  C  and  may  be  empty.  If  overlaps  then 

will  be  empty.  This  set  of  sublists  includes  every  task  in  L,  and  with  no  permuta¬ 
tion  of  the  original  ordering.  Then: 

1 .  is  4  .|  appended  to  y  . 

2.  is  the  list  starting  at  y^  and  continuing  to  the  end  of 

Including  Note  that  since  y^  and  *r^4.i  may  overlap,  a.  is 

not  their  concatenation. 

3.  fi2  Is  appended  to  4^. 

Now  for  the  proof  that  the  worst  case  latency  of  C  in  L  Is  the  maximum  of 

I«il.  I«2l'  ••  ■•l•|,l•l<»2l>• 

Since  the  «^'s  are  all  the  critical  windows  in  L,  they  represent  all  the  lists  a 

such  that  t«]  cannot  be  expanded  in  either  direction  without  the  resulting  interval 
containing  C.  Similarly,  and  [/S^  cannot  be  expanded  on  their  bracketed  sides 

without  Introducing  C  to  the  interval.  Since  the  concatenation  of 
«i>  «2’  '  ‘  ‘  **/)•  ^2^  contains  L,  and  none  of  these  sublists  can  be  expanded 

writhout  the  resulting  sublist  containing  C,  the  only  possibility  for  the  existence  of  a 
sublist  with  greater  latency  is  that  there  Is  such  a  list  which  includes  parts  of  two 
of  the  above  sublists.  That  such  a  sublist  with  greater  latency  does  not  exist  is 
demonstrated  by  case  analysis. 

Again,  consider  the  list  L  reorganized  as  in  equation  (5.2).  Now,  suppose  that 
there  exists  a  sublist  4  which  Includes  part  of  and  part  of  a.|,  and  that  |4|  > 

|3i|  and  |4|  >  |«.||.  The  sublist  4  cannot  begin  in  4i>  or  it  could  not  contain  any¬ 
thing  past  7.|  (without  containing  C)  and  hence  |4|  <  But  if  4  starts  at  the 

beginning  of  It  could  include  no  more  than  a.|,  and  therefore  |4|  ^  |«.||.  If  4  be¬ 
gins  past  the  beginning  of  -y^,  it  cannot  contain  anything  past  y^,  and  hence  |4|  < 
!•.!  |.  Thus  such  a  sublist  4  does  not  exist. 

The  same  line  of  reasoning  will  show  that  a  sublist  with  greater  weight  than 
any  of  {fi^,  •  ,a^,  /Jg}  cannot  being  constructed  from  parts  of  adjacent  a^’s, 

or  and  the  worst  case  latency  of  C  In  L  will  be  the  maximum  of  (||l.||, 

hi  I*  •  •  •  •  l•„|.  }fi2^y  ° 

Algorithm  6.1,  FLATENCY,  summarizes  the  procedure  to  be  followed  in  finding  the 
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worst  case  iatency  of  a  constraint  C  with  respect  to  a  finite  Hat  L. 

Algorithm  5.1.  FLATENCY(L,  C) 

Inputs:  L,  a  list  of  task  Identifiers  (a  basic  control  structure);  !.{/]  Is  the  ith  task 
in  L. 

C,  the  constraint  (also  a  list  of  task  identifiers):  C[/]  is  the  /th  task  in  C. 
Outputs:  (1(C),  start_index,  finishjndex); 

1(C)  is  the  worst  case  latency  of  C  in  L. 

start_index  is  the  index  of  the  first  task  of  the  sublist  of  L  which  displays 
the  worst  latency  for  C. 

finish_index  is  the  index  of  the  last  task  of  the  subllst  of  L  which  displays 
the  worst  latency  for  C. 

Method: 

1.  Scan  L  to  find: 

5^1  the  head  of  L  with  least  weight  which  contains  C. 

a^,  /  s  1  to  n  where  n  Is  the  number  of  occurrences  of  C  In  L 
minus  1. 

|92>  the  tail  of  L  with  least  weight  which  contains  C. 

This  is  accomplished  as  follows.  All  scans  start  from  the  mark  point,  initial* 
lyL[1]. 


a.  Reset  the  mark  point  to  be  the  first  occurrence  of  C[1]  found 
during  each  scan.  If  rw  occurrence  of  C[1]  is  found,  the  mark 
point  is  set  to  the  task  past  the  end  of  the  current  scan. 

b.  is  found  by  scanning  until  a  complete  occurrence  of  C  has 
been  found. 

c.  The  Of’s  are  the  lists  which  exactly  contain  two  occurrences 

of  C;  they  are  found  by  scanning  from  the  mark  point  for  one  oc* 
currence  of  C,  and  then  scanning  from  the  new  mark  point  for  the 
second  occurrence  of  C. 

d.  $2  result  of  the  final  scan  it  no  tall  of  L  is  a  critical  win* 
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dow. 

e.  If  no  occurrence  of  C  is  found  in  L,  return  («,  *1). 

2.  The  weights  of  each  subiist  are  accumuiated  during  each  scan,  as  weli 
as  the  startjndex  and  finishjndex  for  that  scan.  At  the  end  of  each 
scan  the  weight  is  compared  to  the  iargest  found  so  far,  and  saved  as  the 
new  maximum  i(C)  if  it  is  greater  (in  which  case  start_index  and 
flnish_index  are  updated  to  the  vaiues  for  the  Just  scanned  iist). 

3.  Return  the  flnai  vaiues  (MAXIMUM(|^.| |,  |«.||,  -  ‘’i  |a^i.  ^2^^’ 

8tart_index,  finishjndex). 


6.3:  Latencies  of  Constraints  in  Cyciic  Control  Structures 

In  the  specified  language  an  infinite  list  of  tasks  is  generated  by  the  iteration 
construct;  iteration  is  either  applied  to  an  entire  control  structure  or  to  the  last 
closed  control  structure  in  a  <closed  cs  tt8t>.  Thus  infinite  lists  are  either  entirely 
cyclic  (the  entire  structure  is  repeated): 

(A  B  C  D  E)"  (6.3) 

or  have  a  start-up  period  followed  by  a  steady  state  cycling: 

(A  B  C)(D  E)«  (5.4) 

It  would  be  indeed  unfortunate  if  the  entire  infinite  list  had  to  be  examined  to  find 
the  worst  case  latency,  but  due  to  the  restrictions  on  its  cyclic  nature  only  a  rea¬ 
sonably  small  number  of  cycles  (to  be  determined)  have  to  be  examined  to  find  the 
worst  case.  Thus  the  intention  here  Is  to  reduce  the  case  of  an  infinite  list  to  a 
finite  list  which  contains  the  worst  case,  and  use  Algorithm  6.1,  FLATENCY,  on  the 
result. 

The  principle  question  Is  thus  to  determine  how  many  cycles  of  the  iterative 
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portion  of  the  list  need  be  appended  to  the  non-iterative  portion  (if  there  Is  one)  in 
order  to  generate  a  list  containing  the  worst  case  latency  of  a  specified  constraint. 
First,  though,  It  must  be  determined  whether  or  not  the  latency  is  infinite  (assuming 
no  task  id  has  infinite  weight). 

Lemma  5.1.  Given  a  control  structure  (#)(#)*  and  a  constraint  C,  the  worst  case 
latency  of  C  In  (4)(f)*  is  infinite  iff  C  contains  a  task  A  which  is  not  con¬ 
tained  In 

Proof.  If  f  does  not  contain  a  task  A  which  is  In  C,  then  (^)"  is  an  Infinitely  long 
list  (and  hence  of  Infinite  weight)  which  does  not  contain  C,  and  thus  in  which  C 
has  Infinite  latency. 

If  ii  does  contain  every  task  In  C,  then  if  C  contains  n  tasks  at  least  every  n 
repetitions  of  ^  contains  C  and  hence  the  latency  of  C  in  (4)(#)”  could  not  be 
infinite.  □ 


Once  It  has  been  established  that  the  latency  is  not  infinite,  the  following  theorem 
can  be  applied  to  find  the  subllst  which  contains  the  subilst  with  the  worst  case  la¬ 
tency. 


Theorem  6.2.  Given  an  iterative  control  structure  L  =  (f)(f )”  and  a  constraint  C 
containing  n  task  identifiers,  then  if  the  latency  of  C  in  L  is  not  infinite, 
the  list  formed  by  appending  n  -t-  1  copies  of  f  to  4  contains  the  sublist 
with  the  worst  case  latency  for  C  in  L. 

Proof.  Theorem  6.1  established  that  the  worst  case  latency  of  a  constraint  in  a 
list  of  tasks  was  either  a  critical  window  or  a  head  or  tall  of  the  list  5.|  or 

By  Lemma  5.1,  If  the  latency  is  not  infinite  then  ^  contains  every  task  in  C.  There¬ 
fore 


5,  =  (6.6) 

where  f'*  means  n  copies  of  f  appended  to  each  other.  This  is  true  since  n  copies 
of  4>  must  contain  C,  since  each  f  contains  each  task  identifier  In  C.  Note  that 

might  be  wholly  contained  In  nonetheless. 
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By  similar  reasoning: 


(6.6) 

contains  the  most  critical  window  of  (#)(f)*:  if  the  most  critical  window  is  col^ 
talned  In  then  equation  (5.6)  must  contain  it.  Otherwise,  it  is  contained  in 
(#)(f  )”•  If  the  most  critical  window  starts  in  ^  but  ends  in  (#’)*,  then  it  cannot  go 

any  further  than  since  the  first  n  copies  of  #  must  contain  C;  thus  equation 
(6.6)  contains  the  most  critical  window  if  this  is  the  case  also. 

Finally,  suppose  that  (f  )*  contains  the  most  critical  window.  Consider  the  list  # 
formed  by  starting  at  the  first  occurrence  of  C[1]  in  the  first  copy  of  'it,  and  ending 
at  the  last  occurrence  of  C[n]  in  the  n  1st  copy  of  i>.  The  list  #  must  contain 

two  occurrences  of  C,  since  f  ^  through  contain  C,  and  through  contain 

c.  ifW  contains  no  occurrences  of  C,  then  #  is  a  critical  window.  If  #  is  a  critical 
window,  then  no  critical  window  can  exist  which  is  larger  than  #  since  it  would  have 
to  be  constructed  out  of  more  than  n  1  copies  of  i>  and  thus  would  contain  9, 

Thus  if  I  Is  a  critical  window,  it  is  the  most  critical  window  in  (\f)*.  But  if  9  is  not  a 

critical  window,  then  it  must  contain  a  critical  window,  and  by  the  same  logic  this 
critical  window  must  be  the  most  critical  window  in  (V')*.  <=> 

Algorithm  6.2,  ILATENCY,  shows  how  to  use  Theorem  6.2  coupled  with  the  algo- 

rithm  FLATENCY  to  determine  the  worst  case  latency  of  a  constraint  with  respect 

to  any  control  structure  which  does  not  contain  preemption. 

Algornhm  6.2.  ILATENCY(L,  C) 

Inputs:  L,  a  control  structure  which  does  not  contain  preemption. 

C,  a  constraint  (list  of  task  identifiers). 

Outputs:  (1(C),  startjndex,  num.tasks) 

1(C),  the  worst  case  latency  of  C  in  L. 

start_lndex,  the  index  In  L  of  the  first  task  of  the  list  whose  weight  is 
KC). 

num.tasks,  the  number  of  tasks  in  the  list  whose  weight  Is  1(C). 


Method: 

1.  If  L  is  not  Iterative,  let  (1(C),  start_index,  flnishjndex)  b  FLATENCY(L, 
C);  return(l(C),  start_index,  flnish_index  •  start_index  ♦  1 ). 
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2.  If  L  is  iterative,  then  divide  L  into  Its  iterative  and  non-iterative  (if 
any)  parts;  L  =  (♦)(#)". 

a.  If  does  not  contain  every  task  in  C  (not  necessarily  in  ord¬ 
er),  return(«,  -1,  -1). 

b.  Let  K  a  where  n  is  the  number  of  tasks  in  C.  Let 

(1(C),  starUndex,  flnlshjndex)  =  FLATENCY(K.,  C);  return(l(C), 
start_index,  finish_lndex  •  startjndex  ‘•■1). 

6.4:  Latencies  of  Constraints  in  Preemptible  Control  Structures 

The  next  complication  to  be  dealt  with  is  the  presence  of  event  variables  and 
multiple  priority  levels,  implying  the  possibility  of  preemption  before  completion  of  a 
constraint,  and  thus  additional  weight  for  the  worst  case  latency.  In  fact,  at  this 
point  the  possibility  of  Infinite  latencies  arises  due  to  lockout  by  higher  priority 
tasks,  even  though  the  constraint  may  be  contained  in  an  iterative  portion  of  the 
control  structure. 

The  general  case  of  preemptible  control  structures  contains  many  additional 
complexities.  If  one  includes  external  termination  of  control  structures,  non- 
preemptible  tasks,  codestripping,  restarting,  and  idle  time  due  to  stopping  the  flow 
of  control.  Thus,  In  keeping  with  the  theme  of  building  a  hierarchy  of  algorithms 
which  handle  increasing  complexity  with  each  new  layer,  the  applicability  of  the 
next  algorithm  is  restricted  to  include  all  the  control  structures  allowable  as  inputs 
to  ILATENCY,  plus  those  containing  <event  iistVs  «event  varVs  and  <event  cou¬ 
pled  llst>’s).  Specifically  there  are  the  following  restrictions; 

1.  No  external  termination  (<abort  tid>  or  <abort  cs>). 

2.  No  restarting  of  control  structures  (<restart  C8». 
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3.  No  codestripping  «codestripped  cs>). 

4.  No  non-preemptible  tasks  «non*preemptible  tid>  or  Cnon- 
preemptible  closed  cs>). 

6.  No  stopping  of  LC.  The  highest  priority  ready  task  must  al¬ 
ways  be  initiated  without  delay.  Thus  a  control  structure  such 
as: 


((((A«/e1)B)/e2)C)«  (6.7) 

la  illegal  but 

((((A«/e1)B)«/e2)C)«  (6.8) 

la  not.  Event  coupled  lists  must  contain  breaks  (cf.  Section 
2.8.1)  to  ensure  that  waiting  for  higher  priority  events  in  the 
event  coupled  list  does  not  occur. 

0.  Constraints  must  be  contained  wholly  in  a  subcontrol  structure, 
defined  as  a  series  of  basic  cs's,  an  iterative  cs,  or  closed  cs 
lists  at  a  single  priority  level,  in  CFG  terms,  a  subcontrol  struc¬ 
ture  is  an  acyclic  path  through  the  control  structure’s  CFG  which 
contains  no  event  arcs,  back  arcs  or  breaks.  This  allows  all  pro¬ 
cessor  time  spent  at  any  other  level  to  be  treated  as  an  addition 
to  worst  case  latency,  and  lets  the  details  of  exactly  which 
tasks  are  contributing  to  the  increase  be  ignored.  Additionally, 
the  tasks  of  the  constraint  must  not  be  contained  in  more  than 
one  subcontrol  structure.  If  they  are,  then  the  worst  case  laten¬ 
cy  in  the  entire  control  structure  would  be  s'  the  minimum  of  the 
worst  case  latencies  in  each  subcontrol  structure  which  contains 
the  constraint;  thus  the  present  algorithms  still  give  an  upper 
bound.  The  problem  here  is  that  if  the  constraint  can  be  satisfied 
by  an  execution  which  spans  two  or  more  priority  levels,  then  the 
tasks  being  executed  during  preemption  must  be  identified,  and 
can  no  longer  be  lumped  together  and  treated  as  time  lost  to  in¬ 
terrupts. 

7.  Infinite  event  queues.  An  Infinite  number  (or  some  suitably 
high  number  representing  the  maximum  possible  number  of  pending 
events)  of  occurrences  of  each  event  are  remembered.  This 
means  that  if  an  event  happens  before  the  previous  occurrence 
has  been  cleared  (by  completion  of  the  initiated  control  struc¬ 
ture),  the  new  occurrence  will  be  held  in  a  queue  and  not  ignored. 
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5.4.1:  Deffnitions  and  General  Approach 

The  addition  of  preemption  to  a  contrt^  structure  Introduces  several  interesting 
timing  questions.  For  example: 

1.  The  worst  case  latency  of  a  constraint  as  previously  defined, 

1. e.  the  longest  time  that  can  pass  without  their  being  a  complete 
execution  of  each  task  in  the  constraint  in  order.  This  may  now 
be  prolonged  by  initiation  delay  as  well  as  preemption  delay.  Ini¬ 
tiation  delay  is  time  lost  due  to  the  initiating  event  not  yet  having 
occurred. 

2.  The  worst  case  latency  of  an  event,  defined  as  the  longest 
time  that  can  elapse  between  the  occurrence  of  an  event  and 
the  start  of  the  subcontrol  structure  which  it  initiates.  What  ex¬ 
actly  constitutes  the  initiation  of  s  subcontrol  structure  will  be  im¬ 
plementation  dependent. 

3.  Related  to  (2),  it  may  be  desired  to  know  the  worst  case  exe¬ 
cution  time  of  a  list  of  tasks  at  a  given  priority  level;  this  Is  their 
execution  time  in  the  absence  of  preemption  plus  the  most  possi¬ 
ble  time  lost  to  preemption.  This  may  be  more  useful  than  (1)  in 
cases  where  occurrence  of  an  event  signals  the  arrival  of  new 
data,  rather  than  assuming  that  task  initiation  is  unsynchronized 
urith  data  arrival  times. 

In  all  these  cases  it  will  be  necessary  to  make  some  assumptions  which  could 
lead  to  an  upper  bound  which  is  somewhat  greater  than  the  actual  worst  case  (in 
addition  to  the  uncertainty  In  the  estimate  of  worst  case  task  execution  time).  In 
particular,  Teixeira  has  shown  [Teixeira  78]  that  the  worst  case  occurs  when  all 
interrupting  events  happen  at  the  beginning  of  an  interval  and  continue  happening 
at  their  maximum  rate.  It  may  be  that  the  phase  relationships  of  the  events  cou¬ 
pled  with  the  execution  times  of  their  subcontrol  structures  Is  such  that  the 
events  could  never  all  happen  together;  if  this  is  known  in  a  particular  case  then 
its  worst  case  may  be  different,  and  the  Initial  phases  of  the  events  could  be  ad¬ 
justed  accordingly.  The  algorithms  do  allow  specification  of  event  phases,  as  will 
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be  seen.  In  any  case  the  algorithms  do  give  an  upper  bound  to  the  problem. 

The  worst  case  latency  of  a  constraint  which  executes  at  priority  0  (the 
lowest  priority)  can  be  determined  in  terms  of  nominal  time  in  the  absence  of 
preemption  plus  time  lost  to  Interrupts;  the  initiatior  delay  need  not  be  considered. 
The  fundamental  difference  between  tasks  at  priority  0  and  priorities  greater  than 
0  Is  that  if  the  worst  case  latency  of  a  constraint  involves  more  than  one  execu¬ 
tion  of  tasks  at  a  priority  level  greater  than  0,  there  may  be  delay  due  to  initiation 
of  that  priority  level  (which  must  be  figured  according  to  of  the  initiating 

tnoX 

event  in  the  worst  case)  for  the  additional  task  executions.  The  lowest  priority 
level  Is  assumed  to  be  always  running  or  ready,  and  thus  has  no  such  delay. 

in  general  there  will  be  some  thought  required  to  pinpoint  the  worst  case  for 
any  time  interval  of  Interest;  once  determined,  the  algorithm  to  measure  such  a 
time  interval  can  be  constructed  using  the  following  basic  technique. 

1.  Determine  the  relative  priorities  of  every  basic  cs  In  the 

overall  control  structure,  and  associate  with  each  event  variable 

the  subcontrol  structure  which  it  initiates  (cf.  Section  2.6.6).  The 

priority  of  a  subcontrol  structure  and  its  initiating  event  are  the 

same.  It  is  assumed  that  ir_,_  and  are  known  for  each 

mtn  max 

event  (cf.  Section  4.3). 

2.  Determine  whether  the  time  Interval  (latency  or  otherwise)  Is 
Infinite.  This  may  be  done  in  two  steps: 

a.  If  the  time  Interval  is  infinite  in  the  absence  of 
preemption  (determined  as  previously  shown),  then  it  is 
Infinite  in  the  presence  of  preemption. 

b.  Otherwise,  find  out  whether  higher  priority  tasks  can 
sufficiently  load  down  the  processor  so  that  the  interval 
of  interest  Is  never  completed.  One  method  for  doing 
this  win  be  shown. 

3.  If  It  is  not  infinite,  determine  the  interval  In  the  absence  of 
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preemption  and  other  delays. 

4.  Factor  in  the  loss  of  time  due  to  preemption  and  other  delays: 
lifting  any  of  the  restrictions  given  in  Section  6.4  will  usually  be 
seen  as  perturbations  of  this  factor. 


6.4.2:  Finding  Infinite  Latencies 

The  control  structures  represented  here  provide  no  a  prior!  method  of  guaran* 
teeing  fairness  if  preemption  is  present;  i.e.,  it  is  entirely  possible  that  in  the 
worst  case  some  tasks  in  the  control  structure  may  never  be  executed  due  to 
preemption  by  higher  priority  tasks. 

Fortunately  It  is  possible  to  determine  whether  this  Is  the  case  in  advance  and 
at  low  computational  cost,  and  this  must  be  done  before  continuing  with  the 
analysis.  If  the  latency  at  a  given  priority  level  Is  Infinite  then  the  iterative  solu¬ 
tions  to  be  used  for  solving  for  loss  of  time  due  to  preemption  do  not  converge. 
The  method  used  Is  to  determine  a  load  factor  for  each  subcontrol  structure  that 
can  preempt  a  given  one,  and  if  the  load  Is  ^  1  then  the  given  control  structure’s 
tasks  will  never  execute. 

In  order  to  find  the  load  factor  due  to  a  subcontrol  structure  ^  with  Initiating 
event  e^,  It  is  necessary  to  partition  the  set  of  events  in  the  overall  control  struc¬ 
ture  as  follows: 

1-  ‘  ^  events  which  can  always  preempt  but 

can  never  be  preempted  by  e^.  These  are  the  events  of  higher 
absolute  priority  than  e^,  as  found  by  Algorithm  2.2. 

t/e’  **  ^  events  which  cannot  preempt  f 
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and  cannot  be  preempted  by  e^.  but  are  chosen  over  e^  if  e^ 

and  one  of  them  are  both  pending  at  the  same  time.  This  set  is 
the  union  of  the  following  sets: 

a.  Events  which  have  the  same  absolute  priority  as  e^, 
but  occur  to  Its  left  in  the  same  event  coupled  list. 

b.  Events  which  have  the  same  absolute  priority  as  e^, 

but  occur  in  a  different  event  coupled  list  which  Is  entire¬ 
ly  to  the  left  of  the  event  coupled  list  containing 

c.  Events  which  have  higher  absolute  priority  than  e^ 
but  occur  in  an  event  coupled  list  which  does  not  contain 

^/ose  tie'  events  which  cannot  preempt  # 

and  cannot  be  preempted  by  e^,  but  e^  is  chosen  over  one  of 

them  if  both  are  pending  at  the  same  time.  This  set  of  events  is 
the  union  of  the  following  sets: 

a.  Events  which  have  the  same  absolute  priority  as  e^, 
but  occur  to  Its  right  in  the  same  event  coupled  list. 

b.  Events  which  have  the  same  absolute  priority  as  e^, 

but  are  In  a  different  event  coupled  list  which  Is  entirely 
to  the  right  of  the  event  coupled  list  containing  f . 

c.  Events  which  have  a  lower  absolute  priority  than  e^, 
but  occur  in  an  event  coupled  list  which  does  not  contain 

4.  Ejjqifqj-  i  This  is  the  set  of  events  which  can  never  preempt 
e^,  and  initiate  subcontrol  structures  which  can  always  be 
preempted  by  e^.  These  are  the  events  of  lower  absolute  priori¬ 
ty  than  e^. 

As  an  example,  consider  the  control  structure: 


(A/(e1:B/(a2:C|e3:0)|e4;E/(e6:F|ee:6)))” 


(6.9) 
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its  preemption  structure  appears  In  Figure  6.2.  and  the  partitioning  of  Its  events  in 
Figure  5.3. 


Fig.  6.2.  Preemption  structure  for  (5.0). 
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none 

e6/F 

none 

e2,  e3 

el,  eO 

e4 

ee/6 

none 

e2,  e3,  e6 

el 

e4 

Fig.  6.3.  Partitioning  the  events  of  (6.9). 


To  decide  whether  a  task  A  at  a  given  priority  level  in  a  control  structure  may 
never  execute,  partition  the  events  of  the  control  structure  relative  to  A  as  Just 
described.  Each  event  initiates  a  subcontrol  structure  (at  a  single  priority  level); 
let  Initiate  subcontrol  structure  The  worst  case  load  of  a  given  subcontrol 
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structure  on  the  processor  occurs  when  Its  initiating  event  happens  at  its  maximum 
frequency: 


Worst  case  load(#^)  » 


(6.10) 


The  total  load  factor  is  the  sum  of  the  worst  case  load  factor  for  each  event  which 
might  participate  In  the  blockout  of  A;  this  is  the  set  E^^empfs  “ 

^^a/ways  t/e^‘  these  are  exactly  those  events  which  consistently  get 

control  over  e^  no  matter  how  long  e^  may  have  been  waiting  in  queue.  Of  course. 


If  A  Is  in  the  lowest  priority  control  structure,  there  Is  no  e^  and  the  set 

Is  empty;  but  the  analysis  of  possible  blockout  due  to  preemption  Is  unchanged. 
Let  the  events  in  be  {e^,  •  •  •  ,9j}i  then  the  total  load  factor  is; 


Total  load  factor(A)  =  *2^ - 

A-/  ^ 


(6.11) 


If  the  total  load  factor  Is  k  1.0,  then  the  task  A  (and  any  other  task  In  the  same 
basic  cs  as  A)  never  gets  executed;  its  worst  case  latency  Is  infinite.  All  the  fol¬ 
lowing  algorithms  assume  that  this  check  has  been  made  before  they  are  called,  so 
that  a  finite  solution  is  known  to  exist. 
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6.4.3:  Delay  Due  to  Preemption 

The  problem  of  determining  the  time  taken  up  by  preemption  lends  Itself  natur* 
ally  to  an  Iterative  solution.  In  the  worst  case  It  must  be  assumed  that  every  in¬ 
terrupting  event  happens  at  Its  maximum  frequency  (once  every  seconds). 

As  the  tasks  Initiated  by  one  interruption  are  being  executed,  there  may  be  addi¬ 
tional  event  occurrences,  causing  further  delay,  etc.  By  equation  (6.11),  if  the 
load  factor  Is  <  1  It  Is  guaranteed  that  at  some  point  the  task  in  question  (the  one 
being  preempted)  will  execute;  but  it  is  not  ciear  when  and  for  how  iong  before  it 
is  preempted  again. 

The  problem  is  then  to  solve  for  the  total  time  taken  to  execute  some  set  of 
tasks  i  of  total  weight  W^,  in  the  presence  of  a  set  of  Interrupting  events 

{e^,  *  *  *  ,  Sy)  which  ail  happen  at  time  zero  and  then  again  every 
seconds,  each  Initiating  subcontrol  structures  with  weights  {W^,  *  *  *  ,  IVy}.  The 
total  time,  T^,  is: 


k~i 


W. 


(6.12) 


The  celling  function  is  chosen  since  the  quotient 


(6.13) 


gives  the  number  of  occurrences  for  e^  In  the  interval  [r^;  but  since  aN  events 
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happen  at  the  beginning  of  the  Interval  (in  the  worst  case)  one  additional  oc¬ 
currence  must  be  added 


1  ♦ 


(6.14) 


but  if  the  event  occurs  at  the  exact  end  of  the  interval  7^  this  occurrence  must 
not  be  counted  since  y  will  already  be  completed  ~  thus  the  choice  of 


(6.16) 


A  quick  iterative  solution  to  (6.12)  Is  had  by  noticing  that  an  excellent  lower  bound 
is  the  solution  to 


(6.16) 


which  is 


k-l^mltf'^k) 


(6.17) 


Notice  that  the  denominator  is  exactly  1  -  Equation  (6.11),  the  total  load  factor, 
which  has  already  been  computed.  Equation  6.17  Implies  that  running  7  with  inter¬ 
rupts  is  like  running  if  on  a  processor  whose  strength  has  been  diminished  by  the 
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load  factor  of  the  interrupting  tasks. 

Thus  equation  (5.12)  is  solved  iteratively  by  letting 


and  then  solving  for  T. 


W.  +  *2^ 
A-/ 


^n-^ 


(6.18) 


(6.19) 


and  stopping  when  T.-T.  .  The  right-hand  side  is  monotonically  Increasing 

with  and  this  process  converges  very  rapidly  since  the  initial  guess  is  so  near 
the  final  value. 

Given  a  computation  which  takes  a  known  time  t  in  the  absence  of  interruption, 
Algorithm  6.3,  PTIME,  computes  the  total  time  taken  to  do  the  computation  In  the 
presence  of  interrupts.  It  is  assumed  that  there  is  no  Initiation  delay  involved,  i.e. 
PTIME  finds  the  worst  case  Interval  which  contains  t  seconds  of  time  In  which 
preempting  tasks  are  not  executing. 
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Output:  t^,  the  time  taken  in  the  worst  case  with  interrupts  to  perform  a  computa¬ 
tion  which  takes  t  seconds  without  interrupts  (i.e.,  PTiME  assumes  ali  the 
events  In  happen  as  soon  as  the  computation  starts,  and  con¬ 

tinue  at  their  maximum  rate) 

Method: 


1.  Let  *  t.  Let  {e^,  •  *  •  .  e^}  be  the  events  in  Let 

{Wf,  '  '  •  ,W be  the  weights  of  the  subcontrol  structures  initiated  by 

the  corresponding  events.  Then  solve  equation  (5.18)  for  an  initial  value 
of  T.\  solve  equation  (6.19)  repeatedly  for  T.  using  the  value  of  7.  , 

*n 

ending  when  T.=T.  .  Return(r .  ). 

%  *n 


6.4.4:  Applications  of  PTIME 

Using  the  algorithm  PTIME  one  can  determine  several  real-time  properties  of  in¬ 
terest  for  control  structures  which  meet  the  restrictions  of  Section  5.4.  It  must  be 
kept  in  mind  that  there  Is  a  distinction  between  the  following  two  sets  of  events: 


a.  The  set  of  events  which  can  preempt  a  task  after  it  has  been 
Initiated,  as  well  as  take  priority  over  its  initiating  event  while  it 
is  pending. 

b.  The  set  of  events  which  get  priority  over  an  event  if  it  is 
pending  but  has  not  yet  been  recognized  by  the  processor  (no 
tasks  have  been  initiated  due  to  its  occurrence),  but  cannot 
preempt  any  tasks  in  the  subcontrol  structure  which  that  event 
initiates. 


The  worst  case  latency  of  any  constraint  which  is  in  the  subcontrol  structure 
at  priority  0  can  also  be  directly  determined.  I  he  distinction  between  this  applies- 
dan  and  the  one  Just  mentioned  is  that  the  constraint  need  not  be  contained  in  a 
asi^  oapy  of  the  subcontrol  structure.  Since  the  priority  0  subcontrol  structure 
eae  ne  mutating  event  and  hence  no  initiation  delay,  the  worst  case  latency  of  a 
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constraint  C  can  be  determined  in  two  steps: 

Algorithm  5.4.  PRIOLATENCY(#,  C) 

Inputs:  it  a  subcontroi  structure  which  runs  at  priority  0. 

C,  a  constraint. 

Output:  1(0,  the  worst  case  latency  of  C  in  #. 

Method: 

1.  Find  (1(C),  start_index,  num.tasks)  =  ILATENCY(f,  C),  the  worst  case  la¬ 
tency  of  C  in  the  absence  of  preemption. 

2.  Let  I®®  the  set  of  all  events  in  the  entire  control  structure. 

The  worst  case  latency  of  C  is  PTIME(I(C),  ). 

Another  application  is  to  determine  the  latency  of  an  event  e^,  that  is,  how 

long  is  It  in  the  worst  case  between  the  occurrence  of  an  event  and  the  initiation 
of  the  corresponding  subcontrol  structure.  This  can  be  found  as  follows: 

Algorithm  6.5.  ELATENCY(«.  e^) 

Inputs:  •,  the  least  amount  of  time  that  can  elapse  before  a  task  can  be  con¬ 
sidered  initiated. 

e^,  the  event  whose  latency  Is  being  determined. 

Output:  t.  ,  the  longest  time  that  can  elapse  after  e.  occurs  before  Its  subcontrol 
•/  ' 
structure  gets  initiated. 

Method: 

1.  Let  the  set  “  ^w//i_We> 

2.  t,^  -  PTIME(.. 
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5.4.6:  Adding  Phase  Relationships  to  PTiME 

For  a  more  general  formulation,  it  is  useful  to  have  available  the  means  of 
determining  execution  time  in  the  presence  of  interruptions  when  the  Interrupting 
events  may  have  started  happening  at  any  Individually  determined  time  rather  than 
all  starting  at  time  zero.  For  this  purpose,  the  phase  of  an  event  is  here  defined  as 
the  time  since  its  last  occurrence.  Thus  for  a  set  of  events  {e^,  ■  •  •  ,  Qj}  there 

may  be  associated  a  set  of  phases  i  -  •  •  •  ,  If  the  events  are  occurring 

at  their  maximum  rates,  then  no  more  than  ~  seconds  can  elapse  before 

the  next  occurrence  of  e^. 

in  addition,  there  may  be  one  or  more  pending  occurrence  of  any  of  the  events 
on  the  event  queue,  so  a  set  of  initially  pending  occurrences  fi  »  {0^,  *  *  *  .  Ry} 

may  be  determined.  These  two  factors  alter  the  time  due  to  preemption  equation 
(6.12)  as  follows: 


A-/ 


(6.20) 


A  good  lower  bound  to  this  Is  its  solution  without  the  celling  function: 


k->l 


yu  ffi  ^mirS^k)  ~  ]  ] 

n*’  wa>  JJ 


_Ary. 


1  -"2 


k-l^min^^k^ 


(6.21) 
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The  solution  Is  again  found  by  solving  (6.21)  for  the  Initial  value  T.  and  then 

•^0 

solving  (5.20)  for  T.  using  the  previous  value  T .  until  they  are  equal.  A  sutn- 

mary  is  given  below  as  Algorithm  6.0,  PHTIME.  Note  that  if  and  0^-0 

for  all  A,  PHTIME  computes  the  same  value  as  PTIME. 


Algorithm  6.8.  PHTIME(t.  E^gempts* 


Inputs:  t,  a  time  which  represents  computation  time  in  the  absence  of  preemption. 

^preempts'  *  events  which  can  preempt  the  computation  talcing  t 

seconds. 


a  set  of  phases,  one  for  each  event  in  E 


preempts' 


0,  a  set  of  initially  pending  occurrences,  one  for  each  event  In 


E 


preempts  ‘ 


Output:  'pA’  the  time  taken  in  the  worst  case  to  perform  a  computation  which 

takes  t  seconds  to  perform  with  no  interrupts.  The  worst  case  involves 
preemption  by  all  the  events  in  as  often  as  possible,  subject  to 

the  constraints  of  d,  0,  and  for  each  event. 


Method: 

1.  Let  W^“t.  Let  {e^,  •  •  •  ,  Oy}  be  the  events  In  Let 

{Wj,  •  •  •  ,  Wj}  be  the  weights  of  the  subcontrol  structures  Initiated  by 

the  corresponding  events.  Then  solve  equation  (5.21)  for  an  initial  value 
Tj,  :  solve  equation  (6.20)  repeatedly  for  T.  using  the  previous  value 

of  T.  ,  terminating  when  they  are  equal.  T.  Is  the  value  to  be  re* 
%-1 
turned  as 
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6.4,6:  Task  Execution  Time  with  Preemption  at  Priorities  >  0 

Algorithm  6.5  gives  a  method  for  determining  the  maximum  time  that  can  elapse 
between  the  occurrence  of  an  event  ey  and  Initiation  of  Its  subcontrol  structure. 

This  is  fairly  simply  done  since  while  ey  is  pending  the  set  of  events  that  can 

preempt  it  Is  static.  Once  its  subcontrol  structure  has  been  Initiated,  however, 
only  events  In  can  Interrupt;  however,  if  any  of  these  events  does  occur, 

any  event  in  E^y^  yy^  will  take  priority  over  resumption  of  ey’s  subcontrol  struc¬ 
ture. 

This  complicates  the  determination  of  worst  case  execution  time  (and  laten¬ 
cies,  as  will  be  seen  in  the  next  section)  for  a  task  subset  I  of  the  subcontrol 
structure.  Note,  however,  that  if  the  set  E^y^^  yy^  Is  empty  (and  therefore  the  set 

of  Interrupting  events  is  static),  that  PHTIME  can  be  used  to  get  the  correct  result. 

In  general  though,  the  result  must  be  found  in  stages,  determining  when  I  can 
be  executed.  The  next  algorithm  determines  the  worst  case  time  to  execute  a  set 
of  tasks  I,  contained  In  a  single  subcontrol  structure,  given  the  sets  of  events 
^a/ways  ^win  tie  initial  values  of  A  and  0.  It  assumes  that  I 

has  been  Just  initiated  and  then  finds  the  time  from  initiation  to  completion  of  (. 

This  is  done  by  first  finding  how  long  it  will  be  before  all  the  pending  interrupts.  If 
any  (based  on  ^  and  0),  are  processed  and  I  can  be  resumed.  Then  the  earliest 
occurrence  of  an  event  In  marks  the  next  preemption  of  1.  At  that  point 

any  accumulated  occurrences  of  events  in  E^y^y^^  yy^  will  cause  executions  of  their 

subcontrol  structures  to  be  completed  before  I  can  be  resumed.  This  partitioning 
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of  the  total  time  taken  to  execute  I  is  repeated  until  all  of  I  is  completed.  Note 
that  the  method  does  not  require  determination  of  an  exact  schedule  for  all  the 
tasks  In  the  control  structure,  although  the  exact  times  when  I  will  be  executed 
are  found.  Algorithm  6.7,  SCSTIME  (for  "subcontrol  structure  execution  time^)  de¬ 
tails  the  procedure.  Note  that  this  algorithm  does  not  address  the  problem  of 
determining  execution  time  for  a  set  of  tasks  which  may  require  more  than  one  In¬ 
vocation  of  a  subcontrol  structure. 

Algorithin  5.7.  SCSTIMEd,  CMr/zi.t/e- 

Inputs:  I,  a  subllst  of  the  tasks  in  a  subcontroi  structure. 

^a/ways’  '■®****''®  ®|'  Initiating  event. 

Wwa*  ®l’ 

4,  phases  for  events  in  ^^^wlnjle' 

0,  Initially  pending  occurrences  for  events  In  Ue' 

Output:  tp,  the  longest  possible  time  to  execute  I  with  interruptions. 

^wln  tie*  phases  for  all  the  events  In 

^wln  tie*  number  of  pending  occurrences  for  all  the  events  in 

^wlnjtle' 

Method: 

1 .  Set  "  0,  the  cumulative  execution  time  for  I.  Set  ( >  0. 

2.  Find  how  long  I  can  execute  before  it  Is  preempted  by  an  event  from 
^always’ 


*2  "  M'NIMUM  -  ♦* )  for  all  e^  « 


(6.22) 
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Go  to  step  (4). 

3.  Find  how  long  I  can  be  executed  before  an  event  from 
preempts  it;  this  occurs  at  time: 

<2  ■  (least  multiple  of  )  >  f  ^  for  ail  e^  e  )  (6.23) 

4.  If  ^  1*1'  *  complete  in  this  interval;  compute 

4  |l|  •  compute  using  equation  (5.25)  and  substituting 

for  (2'.  compute  using  equation  (5.24)  and  substituting  for  <2- 

ftoturn  (f^.  i^y^  yy..  0'^y„_tye>-  Otherwise  set  *  *2  '  *  1  ' 

6.  Set  0  >  1  for  the  event  from  which  caused  the  preemption. 

Some  events  In  may  also  be  pending: 


*2 

*1 

for  all  e^ 


®  ^w/n.l/e 


(6.24) 


0.  Update  phases  for  all  events: 


*2‘ 


*«  *  <^a/ways  «  ^w/n_f/e> 


(5.26) 


7.  Find  new  value  of  t  .| ,  the  next  resumption  time  of  I: 

•  1  -  '2  •  “  '»/»-».•  ®>  <®  *®> 

8.  Repeat  steps  (3)  through  (7)  until  termination  of  I  Is  detected  In  step 
(4). 
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6.4.7:  Latencies  for  Constraints  at  Priorities  >  0 

The  worst  case  latency  may  be  desired  for  a  constraint  which  Is  satisfied  by 
an  execution  of  a  aubcontrol  structure  at  a  priority  greater  than  0.  If  the  execu¬ 
tion  which  represents  the  greatest  latency  involves  two  or  more  invocations  of  that 
aubcontrol  structure,  the  possibility  of  initiation  delay  must  be  considered  as  well 
as  Interruption  delay.  Each  of  these  delays  may  Involve  a  different  set  of  preempt¬ 
ing  events. 

There  are  thus  several  complexities  to  be  dealt  with  in  the  general  case,  even 
with  control  structures  meeting  the  restrictions  of  Section  5.4;  however  there  are 
also  several  special  cases  with  simpler  solutions.  An  example  is  when  the  sets 
f/e  *^/ose  tie  «nipty:  It  will  be  shown  how  to  make  use  of  this 
simplification  in  a  later  section. 

Recall  the  notation  of  Section  5.2,  where  a  subcontrol  structure  was  broken 
down  into  components  •  ,  e^.  relative  to  a  constraint  C,  where  the 

•^*s  were  critical  windows  and  the  Ify’s  each  contained  one  occurrence  of  C. 

The  worst  case  latency  of  C  in  a  control  structure  containing  il'  at  a  priority 
level  greater  than  zero  Is  found  as  follows.  Let  be  the  initiating  event  for  #. 

There  are  two  candidate  time  Intervals  which  may  be  the  worst  case  latency  for  C. 
The  first,  t^  ,  is  the  maximum  delay  between  occurrences  of  e^  plus  the  maximum 

delay  to  complete  /I.  with  preemption.  The  second,  t  ,  Is  the  maximum  time  taken 

m 

to  complete  e^,  the  most  critical  window  of  #,  also  with  preemption.  Either  one 


may  involve  more  than  one  invocation  of  and  hence  initiation  delay.  To  show 
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that  either  t.  or  t  could  be  the  worst  case  latency  for  C,  consider  a  simple  ex- 
m 

ample: 

Example  6.1.  ((AVa1)B  C  0  O* 

where 

e^„y(e1)  *10  sec. 

|A|  *  1  sec. 

|B|  *  2  sec. 

|C|  *  1  sec. 

|0|  >  3  sec. 

The  most  critical  window  for  the  constraint  (C)  is  (C  D  C),  with  a  weight  of  6 
seconds.  However,  the  longest  time  that  elapses  without  an  occurrence  of  C  is  13 
seconds,  which  Is  or  *  N  *  |C|.  If  |D|  were  changed  to  be  16 

seconds,  though,  (C  0  C)  would  still  be  the  most  critical  window  for  (C),  but  now 

is  1 7  seconds,  whicti  is  greater  than  . 

•m  ^1 

Thus  the  two  candidate  times  must  be  computed  and  their  maximum  returned 

as  1(C).  Note  that  since  the  entire  control  structure  is  repeated,  the  task  list 

starting  at  $2  and  wrapping  around  through  is  a  critical  window,  call  it  s^,  and 

must  have  weight  greater  than  therefore  $2  cannot  take  longer  than  it  to  exe¬ 
cute,  and  need  not  be  considered  as  a  candidate  for  1(C).  Furthermore,  it  might  be 
thought  that  the  weight  of  plus  the  delay  due  to  Initiation  of  its  second  part,  ^2> 

may  In  total  be  greater  than  the  weight  of  an  otherwise  most  critical  window  which 
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Is  contained  In  f  and  hence  has  no  initiation  delay  associated  with  it.  To  show  this 
Is  untrue,  it  Is  only  necessary  to  show  that  the  weight  of  with  initiation  delay 


must  be  less  than  t  and  U  . 

•/» 


since  the  addition  of  delays  due  to  interruptions  is 


a  monotonically  Increasing  function  of  the  time  taken  without  interruptions. 

Thus  assume  that  is  not  the  most  critical  window  of  for  C  (if  it  is,  it  will 


be  considered  by  the  algorithms  and  thus  there  is  no  need  to  Justify  Its  exclusion). 
But  if  this  is  the  case,  than  there  Is  a  critical  window  In  with  greater  weight 


than  m^;  thus  the  time  to  execute  is  less  than  or  equal  to 


In  the  absence  of  Interruptions.  But  since  Is  i  |a^|,  equation  (6.22)  Is  $ 
*ffM.y(*f)*  ^(1’  includes  y^^^(e^)  as  one  of  its  sum¬ 

mands.  Thus  it  Is  sufllclent  to  find  the  maximum  of  t.  and  t 

Consider  the  computation  of  t  .  first  the  most  critical  window  must  be  found 

m 

for  C  in  f  using  the  algorithm  for  iterative  control  structures,  ILATENCY.  Note  that 
In  this  case  since  the  entire  subcontrol  structure  gets  repeated,  the  head  (/l.|)  of 

(#)*  containing  C  cannot  represent  the  worst  latency  for  C  by  itself  (without  initia¬ 
tion  delay):  there  must  be  a  critical  window  of  greater  weight  which  includes 

as  Its  second  occurrence  of  C. 

Therefore  ILATENCY  will  return  1(C),  the  weight  of  the  most  critical  window 

WWW 
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in  (#)*.  ILATENCY  also  returns  start_index,  the  index  in  f/  of  the  first  task  of  m^, 

and  nuffl_tasks,  the  number  of  tasks  in  Knowing  this,  it  can  be  determined  how 

many  times  e^,  the  Initiating  event  for  must  occur  during  execution  (i.e.,  by 

knowing  how  many  copies  of  <i>  are  included  in  m^).  Partition  into  the  sublists 

{e-  where  each  Is  a  portion  of  which  is  contained  in  (a 

^  ll»2  ^ 

single  copy  of)  Since  t^  Is  the  longest  possible  time  to  execute  It  must 

m 

be  assumed  that  all  the  Interrupts  happen  immediately  after  initiation  of  and 
continue  at  their  maximum  rates,  while  the  initiating  event  e^  happens  at  Its 
slowest  rate. 

Figure  6.4  shows  the  time  line  for  part  of  a  sample  execution  of  a  critical  win¬ 


dow  which  is  not  contained  by  a  single  copy  of  #. 


-1  --3- 

'•1  ---4-* 
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• 

flt 
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time 

2 
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Fig.  6.4.  Partial  execution  of  a  critical  window  a^. 

tn 

In  the  worst  case,  the  initiation  delay  of  interval  (4)  will  be  the  maximum  possi¬ 
ble,  with  the  constraint  that  interval  (3)  must  be  at  Its  maximum  too  (greatest 
amount  of  time  lost  to  interrupts).  Therefore  the  intervals  (1)  and  (2)  must  be 
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computed  at  their  minimum,  i.e.  no  preemption.  Thus  interval  (1)  is  assumed  to  be 
zero,  and  Interval  (2)  is  |if|  -  |«^  |.  This  may  give  an  inflated  upper  bound  by 

lengthening  interval  (4);  if  it  is  known  in  a  particular  case  that  preemption  must 
occur  during  intervals  (1)  and  (2),  an  adjustment  can  be  made  in  the  phases  of  the 
Interrupting  events  at  the  beginning  of  interval  (3). 

As  was  previously  stated,  it  is  assumed  that  the  worst  case  is  when  all  events 
occur  right  after  starts,  so  the  length  of  interval  (3),  is  found  from 


1 


(3)* 


0)  where  and  are  deter- 

mined  relative  to  e^,  4  =  (0,  .  .  .  ,  0)  and  0  s  (1,  ....  1)  for  all  the  events. 

Once  the  interval  times  t^.|y  t^^)'  *'’^^(3)  determined,  t^^^  is  found  by: 


\4)  •  ""'"UMfo.  -  V„  *  «(2,  ♦  'o,]  (6-27) 


'*  *(4)  >  0,  there  Is  an  initiation  delay  which  must  be  factored  into  the  solution. 

At  this  point  another  decision  must  be  made  which  affects  the  tightness  of  the 
upper  bound  determined  by  the  algorithm.  During  Interval  (4),  any  of  the  events  in 
the  control  structure  other  than  e^  may  get  control,  and  there  may  be  arbitrarily 

complex  blocking  out  among  the  different  sets  of  events  due  to  the  exact  order  of 
occurrences;  I.e.,  to  got  the  true  picture,  the  sots  t/e 

^/ose  tie  '’***^*^^  every  event  must  be  considered,  since  the  reference  point 
provided  by  knowledge  that  e^  was  pending  has  been  lost.  This  makes  finding  an 
analytic  solution  for  the  values  of  A  and  0  at  the  end  of  interval  (4)  quite  compli- 


9i. 
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cated,  and  two  alternatives  are  provided  here  instead.  Note  that  the  relative  im¬ 
portance  of  this  is  dependent  on  the  relative  size  of  interval  (4);  in  the  extreme 
case,  if  it  is  zero,  then  there  Is  no  problem  at  all. 

The  simpler  method  (and  the  one  used  here)  is  to  assume  that  all  events  in 
^a/ways  ^iv#n  tie  blocked  out  during  interval  (4),  and  thus  their  ♦’s  and  ft’s 

get  updated  accordingly.  This  will  provide  an  upper  bound  which  is  high  by  the 
amount  of  execution  of  preempting  tasks  which  could  have  taken  place  during  inter¬ 
val  (4)  and  will  now  instead  be  added  to  the  preemption  delays  of  the  next  inter¬ 
val. 

Unfortunately,  this  is  not  the  only  complication.  In  the  worst  case,  an  event 
^/ose  tie  control  just  before  the  end  of  interval  (4),  and  Initiate  a 

subcontrol  structure  which  could  not  be  preempted  by  e^.  The  event  e^  In 

^/ose  tie  Initiates  a  subcontrol  structure  that  runs  for  the  longest  time 

without  being  preempted  by  an  event  In  ^m/in  tie  their  4’s  and 

ft’s  at  the  end  of  Interval  (4)}  is  chosen,  since  once  it  gets  preempted  it  has  less 
priority  than  e^  by  definition.  Let  the  length  of  this  time  be  t^,  and  then  the  time 

until  starts  Is  given  by  PHTIME(t^,  ^^win  tie^' 

ft’s  are  updated  and  the  process  Is  repeated  as  from  the  start  of  ,  terminating 


%vhen  the  end  of  «_  Is  reached. 

'"n 

The  alternative  method  Is  to  determine  an  exact  schedule  for  interval  (4). 
Then  It  will  be  known  whether  or  not  an  event  from  can  get  control  and 
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keep  it  past  the  end  of  interval  (4),  and  the  exact  and  O's  for  all  the  events 
can  be  determined.  This  Is  the  method  of  choice  if  the  initiation  delay  is  known  to 
be  significant. 

The  interval  t^  is  measured  on  a  slightly  different  time  line: 


e 

fi 

-1 - 4- 

...| - 6 

e 

$ 

1 

1 

♦ 

1 

occurs 

1 

1 

occurs 

2 

starts 

ends 

second 
t  ime 

starts 

Fig.  6.5.  Partial  execution  of  . 


To  find  t«  ,  the  execution  of 

Pf  1 


is  broken  down  into  parts  which  are  contained  in  a 


single  copy  of  Just  as  was  done  for  Here  the  worst  case  is  when  all  inter¬ 


rupts  happen  at  the  beginning  of  Interval  (1)  and  continue  at  their  maximum  rate, 
since  the  length  of  Interval  (0)  Is  fixed  at  this  gives  the  greatest  delay 

during  Interval  (1).  Interval  (f)  Is  thus  the  maximum  initiation  delay  for  f  with 
preemption,  Including  the  possibility  of  an  event  from  getting  control  Just 

before  e^  happens  and  causing  further  delay  as  previously  discussed.  The  times 


of  the  remaining  intervals  are  found  as  was  done  for  the 


’s,  computing  the  initial 


#’8  and  O’s  appropriately. 

This  procedure  Is  detailed  In  Algorithm  6.8,  LATENCY. 
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Algorithm  6.8:  LATENCY(C,  #) 

Inputs:  C,  a  constraint 

if,  a  subcontrol  structure  containing  ali  the  tasks  in  C,  in  a  control  struc¬ 
ture  meeting  the  restrictions  of  Section  6.4,  and  where  the  worst  case  la¬ 
tency  of  C  is  krrawn  not  to  be  infinite  by  equation  (5.1 1). 

Output:  1(C),  the  worst  case  latency  of  C  in  the  control  structure  containing 

Method: 

1.  Find  1(C),  start_index,  and  num_tasks  by  executing  ILATENCY((if')’*,  C). 
Let  be  the  critical  window  starting  at  start_index  and  continuing  for 

num_tasks. 


2.  Find  the  sublists  of  :  («_  ,  ,  •  •  •  , 

m 

the  completely  contained  in  a  single  copy  of 
if  is  k,  then  ♦[«<«rt-index]  through  f[k], 


)  where  each  is 
/##_  /n. 

n  / 

If  the  number  of  tasks  in 


m. 


through  a 


n> 


n-l 


=  *, 


“in  ®  through  :^[num.tasks  -  k(,n  -  2)  -  (k  -  startjndex  +  1)]. 
n 


3.  Since  the  worst  case  involves  maximum  initiation  delay  for  assume 
Intervals  (1)  and  (2)  (see  Figure  6.4)  elapse  without  preemption.  Thus 
t(i  j  »  0  and  tj2)  ~  1^1  *  1*^  I’  V  “  *(1)  *  '(2)*  start  of  interval 

(3). 


4.  Find  the  sets  Ea/ways’  ^witt  tie  '■®*®^l''e  to  e^.  Set  4  =  0  and  ft  = 


1  for  all  events  in  these  sets.  Find  the  set  relative  to  e^. 


Set 


t  -  0.  Initialize  the  counter  i  -  0.  Repeat  steps  (6)  through  (7)  until 


m 

the  end  of  a  Is  reached  in  step  (6). 
n 


6.  Set  /  -  / 


1.  Find 


\3)  '  V’ 

SCSTIME(a  ,  ^yyi„_tie’  *a  "  *a  ’’  *(3)‘ 

for  the  events  In  to  the  values  and  returned 

by  SCSTIME.  If  /  ■  n,  go  to  step  (8)  where  Is  computed. 


which  Is 
- 1_  + 1/ 


returned  by 
Set  4  and  ft 


6.  At  the  end  of  t^^^ 
^always  “'•*  P®"**'"®' 


,  since  a^  was  in  control,  none  of  the  events  in 
Thus  set  ft  >  0  and: 
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(5.28) 


7.  Let  a  ~  *(3)  *(4)  ^  there  is  an  initiation  delay 

and  the  following  must  be  done: 

a.  Update  4  and  fl  for  each  event  e^  In  U 


"  W’k* 


(6.29) 


^-<(4)*^-®A  W«lc> 


(6.30) 


b.  Find  the  event  e^  s  which  initiates  a  subcontrol 

structure  that  can  run  the  longest  before  (or  without)  being 
preempted  by  an  event  In  f/e^’ 

by  considering  each  event  In  E^^^  In  turn.  Let  t^  be  the 
time  which  eiapses  past  the  end  of  interval  (4)  due  to  e^. 

c.  Find  the  initiation  delay  of  « 


Wiv  '  “  W«.>'  "> 


e.  Set  9^  -  0,  and: 


(6.31) 


for  all  events  e^  in  0  E^,„_j,^}. 

•.  Set  4^  ■  'tfefay' 

If  Is  zero,  set  4^-4^*  t^gj  -  »^(e^). 


(6.32) 
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8.  Find  t0  ;  find  of  (i^)”  by  scanning  untii  the  first  occurrence  of  C 

has  been  scanned.  Divide  into  sublists  as  was  done  for  in  step  (2), 

getting  as  a  result  (d<  ,  *  ■  *  ,  ),  where  this  n  may  be  different 

1  *2  n 

from  the  n  obtained  for  a^. 


9.  Refer  to  Figure  6.6.  The  time  of  interval  (0),  Is 

sume  all  events  In  ^^w/n  tio^  occur  at  the  end  of  this  Interval, 

and  continue  at  their  maximum  respective  rates.  Thus  set  9=1  and  ^  =  0 
for  all  these  events.  Let  -  t^Qj;  lot  /  =  0.  Starting  at  step  (7b),  ex¬ 
ecute  Just  as  for  «^,  substituting  for  t^  ,  and  for  . 

10.  Return  MAXIMUM(t.  ,  t  ). 

m 


6.5:  Special  Cases  and  Extensions 

There  are  many  special  cases  which  result  in  much  simpler  algorithms.  Each  aF 

gorithm  presented  In  the  previous  section  is  directed  towards  a  subset  of  control 

structure  types  which  contains  the  previous  subset  and  some  additional  control 

structure  types;  it  is  seen  that  in  general,  as  the  number  of  different  types  in  the 

subset  increases,  so  does  the  complexity  of  the  resulting  algorithms. 

As  an  example  of  another  important  special  case,  consider  finding  any  of  the 

reaFtIme  properties  for  a  subcontrol  structure  whose  sets  and  E  ,•« 

/ose_i/e  winjtiB 

are  empty,  e.g.,  as  would  be  the  case  In  a  control  structure  containing  no  event 
coupled  lists.  Now  ail  of  the  complications  due  to  having  the  set  of  preempting 
event  variables  change  dynamically  drop  out  ~  the  statically  determined  set 
^always  **  *^®  ®®^  preempt,  and  by  definition  It  can  always  preempt. 
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The  simplifications  this  Introduces  are  substantial;  take  the  most  complex  of  the 
algorithms  of  the  previous  section.  Algorithm  5.8.  LATENCY,  for  example.  In  step 
(6),  SCSTIME  can  be  replaced  by  the  simpler  PHTIME.  There  may  still  be  an  Initia¬ 
tion  delay  but  there  is  no  longer  the  possibility  of  an  event  from 

getting  control  and  prolonging  the  initiation  time. 

As  far  as  extensions  to  the  algorithms  go.  there  are  two  principal  areas  to  con¬ 
sider:  one  is  the  determination  of  algorithms  for  real-time  properties  not  discussed 
here  and  which  are  germane  to  a  specific  application,  and  the  other  is  the  lifting  of 
the  restrictions  of  Section  6.4  to  allow  any  representable  control  structure  to  be 
analyzed.  Since  the  first  area  requires  an  application  relative  to  which  suitable  al¬ 
gorithms  can  be  developed,  only  the  second  area  will  be  covered  here. 

The  difficulty  involved  In  lifting  the  restrictions  of  Section  5.4  varies  consider¬ 
ably  from  one  restriction  to  the  next,  and  hence  they  are  discussed  here  one  at 
time.  The  following  discussions  are  not  intended  to  be  the  final  word  on  the  topic, 
nor  are  all  the  details  supplied  for  a  particular  method  of  lifting  each  restriction. 
Instead,  the  Intention  is  to  point  out  the  difllculties  involved  in  each  case  and  to 
make  suggestions  as  to  how  they  might  be  overcome. 


6.0.1  >  External  Termination 

Recall  that  there  are  t«vo  types  of  iteration,  in  effect,  that  can  be  applied  to  a 
subcontrol  structure;  local  and  global.  If  a  subcontrol  structure  is  locally  cyclic,  it 
means  that  that  particular  subcontrol  structure  executes  Indefinitely,  without  requir¬ 
ing  reinitiation  by  Its  Initiating  event.  This  is  equivalent,  then,  to  having  an  event 
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which  initiates  a  subcontroi  structure  with  inibiite  weight.  If,  instead,  it  is  part  of  a 
globaliy  cyclic  control  structure,  then  it  too  will  be  repeated  indefinitely,  but  only 
one  time  per  initiating  event  occurrence.  Both  of  these  types  are  allowed  under 
the  restrictions  of  Section  6.4,  because  the  weights  of  the  initiated  subcontrol 
structures  are  fixed,  even  though  they  may  be  infinite  in  the  iocally  cyciic  case. 
However,  there  is  the  potentiai  for  a  subcontrol  structure  which  has  infinite  (and 
thus  fixed)  weight  with  no  externai  termination  to  have  varying  weight  in  the  pres¬ 
ence  of  external  termination.  Thus  the  delays  encountered  in  the  execution  of 
lower  priority  control  structures  due  to  Interrupts  which  initiated  <abort  csVs 
(those  which  may  be  externally  terminated)  will  vary  according  to  how  long  the 
<abort  cs>  executes  before  It  gets  preempted.  An  upper  bound  on  this  time  can 
be  found  if  a  good  value  is  known  for  of  the  terminating  event;  if  there  is 

more  than  one  such  event,  the  minimum  of  their  maximum  periods  may  be  used. 

Note  that  this  also  complicates  the  determination  of  load  factor  (equation 
(6.11)),  since  that  depends  as  well  on  having  a  known  upper  bound  for  the  weight 
of  each  subcontrol  structure. 


6.6.2:  Restart  Control  Structures 

This  is  another  case  which  may  lead  to  variable  subcontrol  structure  execution 
times.  Every  time  a  <restart  C8>  gets  preempted,  the  time  of  its  current  execution 
is  extended  by  Its  ruMDlnal  weight  In  the  absence  of  preemption;  It  is  essentially 
the  opposite  of  external  termination.  Thus  a  <restart  C8>  needs  a  nort-preempted 
Interval  equal  to  Its  nominal  weight  In  which  to  execute.  To  find  whether  such  an 
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Interval  exists,  one  must  see  whether  the  phases  of  all  the  events  in  the  sets 
*^a/urjyj  •'’**  ®iiv/#i  f/e  ***«  <restart  cs>  can  be  adjusted  so  that  It  gets 

preempted  at  least  once  every  |<restart  cs>|  •  «  seconds.  This  can  be  either  very 
simple,  as  in  the  case  where  there  Is  only  one  event  that  can  preempt  the  <restart 
cs>,  or  very  complex,  if  there  are  many  events  and  their  interrelationships  must  be 
considered. 


6.6.3i  Codestripping 

This  Is  somewhat  simpler  to  handle.  If  one  of  the  interrupting  events  initiates 
a  <codastrlpped  cs>,  then  the  delay  It  causes  is  simply  its  nominal  weight  divided 
by  the  number  of  codestrips,  e.g.  the  weight  of  (A/6)  is  just  |A|/6.  If  the  tasks 
whose  execution  time  Is  being  measured  are  codestripped,  though,  it  is  as  if  they 
were  preempted  by  an  event  with  variable  -  to  get  this  efFect,  a  dummy 

event  can  be  substituted  for  the  integer  which  tells  how  many  codestrips  there 
are,  and  its  phase  can  be  adjusted  every  time  the  <codestripped  cs>  Is  resumed 
so  that  It  will  cause  preemption  at  the  time  when  a  single  codestrIp  would  have 
finished. 


6.8.4i  Non-Preemptlble  Tasks 

L«t  be  a  subcontrol  structure  whose  real-time  properties  are  being 

mOU 

measured.  Then  If  a  subcontrol  structure  of  higher  priority  than  includes 

non-preemptlble  tasks,  the  effect  on  unnoticeable  ~  these  tasks  would 
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have  been  executed  to  completion  anyway  before  i»_  .  _  was  resumed.  If  all  of 

^meas  **  non-preemptible,  then  its  computation  time  need  not  Include  the  effects  of 

those  Interrupts  which  cannot  preempt  it,  and  the  sets  Ej/m-jyj  >ncl  can 

be  adjusted  accordingly.  If  only  a  part  of  it _  Is  non-preemptible,  then  the  4’s 

and  O’s  of  interrupting  events  must  be  updated  when  the  non-preemptible  part  has 
been  executed.  If  a  subcontrol  structure  of  lower  priority  than  ii _ is  non- 

preemptible,  then  if  the  interval  Includes  an  initiation  delay,  it  must  be  in¬ 

creased  by  the  maximum  amount  possible  due  to  execution  of  tasks  which  e^  can¬ 
not  preempt.  This  can  be  handled  similarly  to  the  case  where  an  event  from 
*^/osa  t/e  control  Just  before  e^  occurs. 


6.6.6:  Stopping  the  Flow  of  Control 

This  is  another  case  which  may  result  in  effectively  varying  the  weights  of 
subcontrol  structures  and  hence  the  delay  due  to  preemptions  which  include  their 
execution.  It  has  some  similarities  to  external  termination;  consider  the  example 
given  in  equation  (6.7),  repeated  here: 

((((AV«  ')B)/e2)C)« 

The  problem  is  that  the  effect  of  the  delay  In  executing  A  due  to  e1*s  occurrence 
is  dependent  on  the  period  of  e2  -  hence  the  similarity  to  external  termination. 
The  difference  Is  that  the  minimum  effective  weight  of  B  is  still  |B|,  since  an  oc¬ 
currence  of  e2  before  the  end  of  B  preempts  B,  but  leaves  the  remainder  of  B  to 
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be  resumed  once  C  is  done. 

Thus  the  techniques  for  external  termination  can  be  applied  here,  with  the  con¬ 
straint  that  the  minimum  weight  of  a  subcontrol  structure  Is  still  its  nominal  weight. 

6.6.6:  Constraints  at  More  than  One  Priority  Level 

To  be  able  to  consider  the  worst  case  latencies  of  constraints  whose  member 
tasks  are  found  at  different  priority  levels  and  thus  in  different  subcontrol  struc¬ 
tures  is  a  difHcult  problem.  To  determine  this,  the  executions  of  tasks  at  lower  and 
higher  priority  levels  can  no  longer  be  lumped  together  and  treated  as  a  delay, 
since  at  the  very  least  it  must  be  known  when  every  task  which  occurs  in  the  con¬ 
straint  Is  executed,  regardless  of  what  its  priority  may  be.  Thus  algorithms  of  a 
very  different  sort  from  those  In  the  previous  sections  are  probably  required,  and 
the  possibility  of  simulation  to  determine  an  exact  schedule  may  provide  a  starting 
point 

6.6.7:  Finite  Event  Okieues 

if  only  a  finite  number  of  event  occurrences  can  be  remembered,  and  this 
number  is  small  enough  so  that  some  event  occurrences  are  Ignored,  then  from 
6 _ ’s  point  of  view,  the  delays  due  to  preemption  computed  previously  may  be 

too  high  but  cannot  be  too  low.  The  equations  which  determine  the  time  lost  to 
preemption  must  be  adjusted  to  Include  e  maximum  value  of  0. 

When  computing  Initiation  delay.  It  must  now  be  seen  whether,  In  the  worst 
ease,  the  Initiation  delay  may  bo  prolonged  due  the  Initiating  event's  occurrence 
being  Ignored. 
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A  new  notation  has  been  given  which  represents  real-time  controi  structures  at 
a  high  (task  and  event)  and  lmpiementatlor^free  level,  Including  sequencing,  itera¬ 
tion  and  preemption  as  primary  constructs.  The  notation  can  represent  convention¬ 
al  single  and  multiple  level  Interrupt  structures  as  well  as  non-traditional  ones 
where  branching  of  the  preemption  structure  is  generalized.  A  total  priority  orders 
ing  may  be  described,  or  arbitrarily  many  events  and  subcontrol  structures  may  re¬ 
side  at  the  same  priority  level.  An  algorithm  is  given  for  determining  the  preemption 
relationship  for  any  <event,  task>  couple  in  the  control  structure,  as  well  as  a  com¬ 
pletely  deterministic  method  of  selecting  a  task  for  service  if  several  events  with 
arbitrary  priorities  are  pending  (possibly  equal).  It  may  be  interesting  to  consider 
the  modifications  necessary  to  the  algorithms  if  It  is  assumed  that  the  processor 
chooses  at  random  from  among  all  the  pending  events  of  the  highest  priority. 

Additionally,  notation  is  given  for  representing  task  termination  by  external 
event  occurrences  (as  opposed  to  temporary  preemption),  describing  whether  a 
control  structure  should  be  restarted  from  its  first  task  or  resumed  from  the  point 
of  preemption,  codestripping,  and  masking  of  a  set  of  interrupts  while  any  given 
task  is  executing.  It  is  shown  that  due  to  the  assumed  transitivity  of  the 
"preempts"  relation,  the  sets  of  events  chosen  for  these  special  cases  might 
necessarily  Include  other  events  not  explicitly  mentioned. 

The  notation  Is  compact,  and  provides  a  convenient  format  for  conveying  a  lot 
of  information  about  the  control  flow  relationships  among  the  members  of  a  set  of 
tasks.  A  complete  BNF  specification  Is  provided,  and  a  parser  can  be  (and  has 
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been)  constructed  using  any  of  a  number  of  extant  compiler^compilers  which  accept 
BNP  specifications. 

Classes  of  representable  control  structures  are  given,  typed  by  the  topoiogy 
of  their  control  flow  graphs.  It  is  shown  that  partial  as  well  as  total  orderings  of 
tasks  and  events  can  be  achieved  through  the  use  of  the  event  coupled  list,  which 
Introduces  forks  into  the  control  flow  graph.  A  method  for  recursively  constructing 
a  multiple  priority  level  control  structure  of  the  traditional  type  is  given.  The  dis¬ 
tinction  is  made  between  a  control  structure  which  supports  a  processor  priority 
and  one  which  actually  has  only  a  single  level  of  interrupts,  even  though  there  may 
be  a  set  of  several  interrupting  events  which  are  ordered  among  themselves.  It  is 
shown  that  while  in  general  the  need  for  this  type  of  control  structure  is  perceived 
to  be  strongest  In  situations  where  representation  of  periodic  events  and  task  exe¬ 
cutions  prevails,  aperiodic  control  structures  are  representable.  However,  a  true 
tree-shaped  interrupt  structure  cannot  be  achieved  due  to  the  transitivity  of  the 
"preempts"  relation.  In  addition,  while  iteration  can  be  applied  to  any  closed  or 
basic  control  structure,  a  back  arc  cannot  originate  from  the  middle  of  one  event 
coupled  list  and  terminate  In  the  middle  of  another.  This  is  not  felt  to  be  a  serious 
restriction,  however,  since  it  is  likely  that  groups  of  tasks  In  a  subcontrol  structure 
are  related  and  expected  to  be  executed  as  a  block. 

The  second  half  of  the  thesis  concentrates  on  describing  the  sorts  of  real-time 
properties  which  may  be  of  interest  to  a  user  of  any  real-time  system,  and  demon¬ 
strating  how  they  can  be  measured  for  control  structures  representable  using  the 
notation  presented  here.  The  worst  case  latency  of  a  constraint  Is  found  to  be  a 
property  whose  determination  involves  computation  of  several  other  properties  as 
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subroutines.  The  difTiculty  of  finding  an  upper  bound  on  task  execution  time  is  dis¬ 
cussed,  although  without  this  knowledge  it  is  doubtfui  that  much  further  analysis  of 
value  could  be  performed.  Additionally,  bounds  on  the  maximum  and  minimum  period 
for  each  event  are  needed.  The  algorithms  reflect  reality  in  that  if  these  periods 
are  not  known,  it  will  be  difficult  to  forecast  real-time  performance  for  the  control 
structure. 

Next  several  algorithms  for  measuring  latencies  are  developed,  each  handling  a 
larger  set  of  control  structure  types,  up  to  a  level  which  includes  the  entire  basic 
framework  of  sequencing,  iteration  and  preemption.  Along  the  way,  it  is  shown  how 
to  determine  if  a  response  time  might  be  infinite,  and  it  is  assumed  that  this  is  done 
before  attempting  to  use  any  of  the  algorithms  for  measuring  the  various  time  inter¬ 
vals.  An  algorithm  is  given  which  determines  the  loss  of  time  due  to  preemption  if 
the  set  of  preempting  events  is  static,  and  by  using  it  it  is  shown  how  to  determine 
the  latency  of  a  constraint  contained  In  a  priority  0  subcontrol  structure,  and  the 
worst  case  initiation  delay  for  an  event  at  a  given  priority  level.  The  worst  case 
assumed  here  Is  the  occurrence  at  the  beginning  of  an  interval  of  all  interrupts, 
and  their  reoccurrence  at  their  individual  maximum  rates.  However,  an  algorithm  is 
also  given  which  determines  preemption  time  if  the  phase  of  each  event  is  known 
at  the  beginning  of  the  interval  being  measured. 

The  effects  on  these  algorithms  of  adding  control  structures  containing  each  of 
the  restricted  Items  of  Section  6.4  is  considered;  further  investigation  is  needed 
here  to  uncover  the  details  of  the  problems  which  are  pointed  out.  Another  useful 
thing  would  be  to  develop  analyses  based  on  a  probabilistic  model  rather  than  on 
the  worst  case;  e.g.,  what  is  the  probability  that  a  given  constraint  will  have  a  la- 
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tency  of  no  more  than  n  seconds?  Finally,  an  Important  result  would  be  the 
development  of  a  general  algorithm  which  could  determine  the  latency  for  any  of 
the  representable  control  structures.  The  difficulty  of  such  a  task  should  not  be 
underestimated;  indeed,  in  the  words  of  Niklaus  Wirth: 

It  does  not  appear  feasible  at  this  time  to  postulate  any  generally 
valid  and  at  the  same  time  practically  useful  rules  for  the  determi¬ 
nation  of  execution  time  bounds  for  systems  using  processor  shar¬ 
ing.  [Wirth  77b] 


Appandix  A:  Summary  of  BNF  for  Real-time  Control  Structures 


<control  structure>  ::=  <basic  cs>  |  <closed  cs>  |  <iterative  cs> 

<task  id>  ::=  <letter>  |  <tasl(  id>  <alphanumeric> 

<ietter>  ::=  A  |  B  |  C  |  ...  |  Z 
<alphanumeric>  <letter>  |  <digit> 

<digit>  0  I  1  I  2  I  ...  I  0 

<baslc  cs>  ::=  <task>  |  <baslc  cs>  H  <task>  |  <basic  cs>  T 
<task>  <task  id>  |  <non-preemptible  tid>  |  <abort  tid> 

<closed  cs>  (  <baslc  C8>  )  |  (  <preeinptible  C8>  )  )  (  <closed  cs  list>  )  | 
(  <closed  cs>  <preemptible  cs>  )  |  (  <closed  cs>  <baslc  cs>  )  | 

(  <re8tart  cs>  )  |  <non-preeinptible  closed  cs>  |  <abort  cs> 

<closed  cs  list>  <closed  cs>  |  <closed  cs  Hst>  <closed  cs> 
iterative  cs>  <basic  cs>*  |  <closed  cs>*  |  <basic  cs>  <iterative  cs> 
<preemptible  cs>  ::s  <control  structure>  /  <event  llst>  |  <codestripped  cs> 
<event  var>  e<lnteger> 

<integer>  <diglt>  |  <integer>  <dlgit> 
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<event  list>  <event  var>  |  «event  coupled  llst»  | 


«event  coupled  list>)* 

<event  coupled  llst>  <event  var>:  <control  structure>  | 

<event  coupled  list>  *|’  <event  var>:  <control  structure> 
<non'preefflptlble  tid>  *<ta3k>  |  ‘(<ev  list»<taslc> 

<non-preemptlble  closed  C8>  '<clo8ed  cs>  |  *(<ev  list»<closed  cs> 
<ev  llst>  ::s  <event  var>  |  <ev  list>,<event  var> 

<abort  tid>  8<task>  |  6«ev  Ii8t»<task> 

<abort  C8>  9<closed  C8>  |  9«ev  llst>)<closed  cs> 

<restart  cs>  ::b  >  <ba8(c  C8>  (  >  (<ev  ffst»  <basic  cs> 

Kcodestripped  cs>  <baslc  cs>  /  <integer> 
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